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ABSTRACT 

TWINKLE  is  a  language  designed  to  aid  in  the  syntactic 
specification  of  programming  languages.   In  addition  to  the  constructs 
available  in  BNF,  TWINKLE  provides  for  easy  specification  of  lists  and 
other  frequently  used  linguistic  structures.   By  providing  a  large  number 
of  alternatives  for  its  various  constructs,  TWINKLE  allows  the  language 
designer  to  specify  a  language  in  terms  that  approach  natural  language. 

The  implementation  of  a  compiler  for  TWINKLE  is  described. 
This  compiler  is  the  first  phase  of  the  ILLIAC  IV  Translator  Writing 
System. 
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1.   INTRODUCTION 

The  recent  proliferation  of  digital  computers  has  spawned  an  ever 
increasing  number  of  formal  languages  for  computer  programming  and  related 
purposes.   Creating  a  compiler  for  such  a  formal  language  is  a  decidedly  non- 
trivial  task,  often  requiring  several  man-years  of  effort.   Therefore,  from 
this  "bourgeoning  stock  of  languages  and  compilers,  several  widely  applicable 
compiler  writing  techniques  have  been  extracted  which  at  once  lead  to  a  deeper 
understanding  of  the  compiler  writing  process  and  to  a  considerable  reduction 
of  the  effort  involved. 

Because  of  its  importance  in  obtaining  a  clear  and  precise  definition 
of  a  formal  language,  the  development  of  syntax  metalanguages  has  been  inti- 
mately related  to  the  development  of  compiler  writing  techniques.   These  meta- 
languages range  from  Backus  Naur  Form  (BNF)  [1],  and  its  many  variants 
[2,  3>  ^>    5]>  to  languages  more  suitable  to  syntactic  recognition,  such  as 
the  Floyd  production  language  (FFL)  [6]  and  operator  precedence  tables  [7]> 
and  even  to  the  conventional  programming  languages,  FORTRAN  [8]  and  PL1  [9]- 
Each  of  these  languages  has  certain  advantages:  relative  compactness  and  clarity 
of  syntactic  structure  in  the  case  of  BNF  and  its  derivatives;  a  very  clear  and 
explicit  statement  of  the  recognition  algorithm  in  the  case  of  FFL  and  operator 
precedence  tables;  and,  finally,  virtually  immediate  implementation  in  the 
case  of  FORTRAN  and  FL1.   As  is  to  be  expected,  ease  of  producing  a  linguistic 
description  decreases  rapidly  as  the  description  itself  approaches  an  imple- 
mented compiler. 

The  primary  aim  of  the  TWINKLE  metalanguage  is  to  provide  a  major 
increase  in  the  ease  with  which  a  syntactic  specification  may  be  created  by 
a  language  designer  and  in  the  ease  with  which  that  syntax  may  be  understood 
"by  a  user  of  the  language  unfamiliar  with  metalanguages  in  general.   This  has 


"been  achieved  through  the  introduction  of  a  wide  variety  of  syntactic  symbols 
for  designating  many  of  the  common  syntactic  structures  such  as  lists,  en- 
closures, etc.,  and  through  the  provision  of  numerous  English  words  and 
phrases,  which  may  be  used  with  commonly  understood  meanings,  as  an  integral 
part  of  the  syntactic  specification. 

As  a  secondary  aim,  TWINKLE  has  been  designed  to  present  a  unified 
front  for  the  University  of  Illinois  Translator  Writing  System  (TWS).   TWINKLE 
is  the  input  language  and  the  TWINKLE  translator  is  the  first  phase  of  the  TWS. 
Thus,  TWINKLE  combines  BNF  as  described  by  Beals  [3]  and  translatable  BNF 
(TBNF)  as  described  by  Trout  [h].      Before  progressing  to  a  detailed  descrip- 
tion of  the  TWINKLE  language  and  translator  which  occupies  the  remainder  of 
this  thesis,  a  brief  description  is  provided  of  both  BNF  and  TBNF. 

1.1  Backus  Naur  Form 

The  basic  unit  of  the  BNF  description  of  a  language  is  the  produc- 
tion. A   production  consists  of  a  nonterminal  (the  left  hand  side)  followed 
by  the  symbol,  triple  "::  =  ",  followed  by  a  list  of  terminals  and  nonterminals 
(the  right  hand  side).  Each  nonterminal  consists  of  a  string  of  characters 

enclosed  in  either  quotes  (" ")  or  angle  brackets  (< >) .   The  string  may 

not  include  ",  <,  or  >  and  may  not  start  with  *.   Terminals  are  special  words 
(strings  of  alphanumeric  characters  preceded  by  #)  or  characters  (A,  B,  C, 
etc)-  Characters  used  in  the  metalanguage  (#,  ",  <,  /,  etc.)  must  also  be 
preceded  by  a  #  when  used  as  terminals.   Two  productions  with  the  same  left 
hand  side  may  be  combined  into  one  by  including  the  right  hand  side  of  the 
second  with  the  right  side  of  the  first  and  separating  it  from  the  latter  with 
the  metacharacter,  "/  ".   Productions  themselves  are  separated  from  one  another 
the  metacharacter,  "j  ". 


1.2  Translatable  Backus  Naur  Form 

TBNF  is,  in  itself,  a  large  step  toward  simplifying  syntactic  spec- 
ification.  In  addition  to  the  BNF  structures  described  in  the  last  section, 
TBNF  allows: 

(i)  Kleene  star-- 

<A>  *  =  \    |  <A>  |  <A>  <A>  |  .  .  .    ; 
(ii)  Ampersand  for  optional  presence  of  some  symbol-- 
<A>  &  =  <A>  |  \    ; 
(iii)   Square  "bracket  construct  to  delimit  groups  of  symbols  and 
alternatives -- 
<X>  ::=  <Y>  [<A>  |  <B>]   z 
is  equivalent  to 
<X>  ::=  <Y>  <D>  z 
<D>  ::=  <A>  |  <B>   ; 
(iv)   list  <A>  =  <A>  <A>  *   ; 

(v)   list  <A>  separator  <B>  =  <A>  [<B>  <A>]  *   ; 
(vi)  <ANY>  =  Any  symbol  at  all   ; 
(vii)  "but  <A>  used  in  conjunction  with  <ANY>  to  reduce  its  generality. 

Thus  TBNF  is  considerably  more  general  than  BNF.  Note,  however,  that  TBNF 
does  not  allow  left  recursion  because  the  parser  generated  employs  recursive 
descent. 


2.   THE  TWINKLE  METALANGUAGE  FOR  SYNTACTIC  SPECIFICATION 

When  work  was  begun  on  the  TWINKLE  language,  two  metalanguages, 
BNF  and  TBNF,  were  already  in  use  at  the  University  of  Illinois  as  input 
languages  to  the  TWS.   The  BNF  input  yielded  a  deterministic  parsing  algor- 
ithm based  on  the  Floyd  Production  Language  (FPL),  as  described  by  Beals 
[  3  ];  while  TBNF  input  yielded  a  recursive  descent  (KD)  parsing  algorithm, 
as  described  by  Trout  [  k   ] .   Each  parser  has  certain  advantages  but, 
once  either  BNF  or  TBNF  has  been  chosen  as  the  metalanguage,  it  requires 
a  major  effort  to  convert  the  description  to  the  alternate  form.  Thus, 
although  it  would  be  desirable,  because  of  its  relatively  rapid  generation, 
to  create  a  RD  parser  during  the  debugging  phases  of  the  language  descrip- 
tion, it  would  be  equally  desirable,  because  of  the  rigorous  exclusion  of 
ambiguity  inherent  in  the  nature  of  the  deterministic  FPL  parser,  to 
create  a  FPL  parser  when  the  last  phase  of  the  compiler  creation  is  reached. 
Unfortunately  this  ideal  has  not  been  attainable,  in  the  past,  primarily 
due  to  the  difficulty  of  translating  TBNF  into  BNF  by  hand.   These  considera- 
tions, therefore,  dictate  that  TWINKLE  be  a  superset  of  both  BNF  and  TBNF, 
so  that  existing  language  specifications  may  be  accepted  by  the  new  system 
with  little  or  no  change,  and  that  the  TWINKLE  translator  output  be  either 
BNF  or  TBNF. 

The  basic  form  of  TWINKLE,  therefore,  is  cast  in  the  familiar 
BNF  mode.   That  is,  a  TWINKLE  syntactic  specification  consists  of  one  or 
more  productions,  each  of  which  has  a  left  hand  side,  which  is  the  non- 
terminal being  defined  (wholly,  or  in  part)  by  the  production,  and  a 

:t  hand  side  which  comprises  a  set  of  alternative  definitions  for  the 


nonterminal  in  the  left  hand  side.   Each  definition,  in  turn,  comprises 
a  string  of  TWINKLE  syntactic  and  semantic  symbols.   In  BNF  the  produc- 
tions are  separated  from  one  another  by  semicolons;  the  definitions  by 
vertical  bars  which  are  actually  rendered  in  the  implementation  by  a 
slash;  and  the  left  and  right  hand  sides  of  a  production  by  the  character, 
triple  "::="  .   It  is  one  of  the  aims  of  the  TWINKLE  project  to  make 
possible  the  rigorous  specification  of  a  language  syntax  in  a  way  that  is 
at  once  acceptable  to  both  human  beings  and  computers.  To  this  end, 
English  phrases  have  been  provided  for  the  replacement  and/or  embellishment 
of  the  metalinguistic  symbolism  of  BNF  and  TBNF.   In  addition,  several 
features  not  present  in  either  BNF  or  TBNF  have  been  introduced.   For 
example,  the  BNF  productions, 

<PROGRAM>  :  :  -  #BEGIN  <LIST  OF  STATEMENTS>  #END  / 

#BEGIN  #END; 
<LIST  OF  STATEMENTS>  : : =  <STATEMENT>  /  <LIST  OF  STATEMENTS>  #; 
<STATEMENT>; 

may  be  written  in  TWINKLE  in  the  much  more  readable  form: 

A  <PROGRAM>  CONSISTS  OF  A  POSSIBLY  EMPTY  LIST  OF  <STATEMENT>S 

(1) 
SEPARATED  BY  SEMICOLONS  ENCLOSED  IN  #BEGIN  AND  #END; 

At  first  glance  this  might  appear  to  have  two  distinct  interpretations: 
particularly,  a  program  may  be  either 

BEGIN  s  ;  s  ;  s  ;  ...  ;  s  END 
or 

s  BEGIN;  END  s  BEGIN;  END  s  ...  BEGIN;  END  s 


where  "s"  here  stands  for  <STATEMENT>.   In  fact,  the  former  interpretation 
is  made.   If  the  language  designer  wishes  to  express  the  latter  form  of 
program,  he  may  write : 

A  <PROGRAM>  CONSISTS  OF  A  POSSIBLY  EMPTY  LIST  OF  <STATEMENT>S 

(2) 

SEPARATED  BY  [SEMICOLONS  ENCLOSED  IN  #BEGIN  AND  #END] ; 

In  TWINKLE,  the  square  brackets  ([])  serve  the  function  of  delineating 
clause  and  phrase  structure  in  productions.   The  enclosure  operator  always 
acts  on  the  immediately  preceding  syntactic  symbol  which  is  at  the  same 
nesting  level  as  the  enclosure  operator,  itself.   Thus,  in  production  (i), 
it  is  the  possibly  empty  list  that  is  to  be  enclosed  and  not  the  semicolons. 
In  production  (2),  on  the  other  hand,  the  square  brackets  associate  the 
enclosure  operator  with  the  semicolons  and  indicate  that  this  construct, 
taken  as  a  whole,  is  to  be  the  separator  of  the  possibly  empty  list. 

It  is  to  be  noted,  however,  that  the  TWINKLE  language  does  not 
enforce  strict  grammatical  usage  of  English  but,  rather,  allows  for  such 
usage  by  the  language  designer.   Thus,  it  will  be  found  that,  in  the  TWINKLE 
syntax,  the  articles  "A"  and  "AN"  are  treated  equally  with  the  result  that 
a  determined  corruptor  of  English  might  write  (l)  as 

AN  <PROGPAM>  CONSISTS  OF  AN  POSSIBLY  EMPTY  LIST  OF  <STATEMENT>S 
SEPAPATED  BY  SEMICOLONS  ENCLOSED  IN  #BEGIN  AND  #END;  ^' 

The  TWINKLE  program,  in  its  most  general  form,  is  made  up  of 
three  distinct  portions,  of  which  the  language  syntactic  description  is 
the  second.   The  first  portion  is  a  set  of  control  statements  which  deter- 
mine, among  other  things,  the  nature  and  volume  of  the  TWINKLE  output  and 


the  processing  options  for  the  remainder  of  the  TWS.   The  construction 
and  use  of  this  portion  is  dealt  with  in  Chapter  3«   The  third  portion, 
the  semantic  tail,  conveys  the  necessary  semantic  information  about  the 
language  being  described.   This  is  discussed  briefly  in  2.2.5,  and  more 
fully  by  Machado  [10].   The  remainder  of  the  current  chapter  is  a 
discussion  of  the  syntactic  and  semantic  symbols  available  to  the  language 
designer  for  the  syntactic  portion  of  the  TWINKLE  system. 

2.1    Syntactic  Symbols 
2.1.1  Terminals 

Terminals  are  those  symbols  of  which  the  object  program  is 
ultimately  composed.  They  may  occur  only  on  the  right  hand  side  of  a 
production  and  are  represented  in  the  syntax  in  a  number  of  different 
■ways.   Terminals  fall  into  the  following  classes:   characters,  special 
words,  character  mode  terminals,  meta-  or  special  class  terminals,  and 
blanks. 
2.1.1.1  Characters 

The  simplest  form  of  the  terminal  is  the  character.  Here 
character  refers  to  any  of  the  twenty- seven  special  characters  accepted 
by  equipment  of  the  Burrough's  B-5500  computer  system.   These  are  included, 
together  with  the  other  thirty- seven  B-5500  characters,  in  Table  I-   In 
the  syntax,  a  character  may  be  represented  by  prefixing  it  -with  a  sharp 
(#)  when  the  character  standing  alone  would  have  some  special  significance 
to  TWINKLE  (i.e.,  when  the  character  is  a  meta- character ) .  For  example, 
a  comma  is  represented  in  the  syntax  by  the  symbol  pair  "#, ".   However, 
since  more  than  half  of  the  special  characters  available  are  meta- characters, 
it  is  probably  safest  to  include  the  sharp  in  all  cases.  This  is  a  point 
at  which  TWINKLE  diverges  from  the  standard  BNF  and  TBNF.   The  latter  have 
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<*!>  - 

0,7 

> 

15 

0,1,4,5 

X 

32 

0,1,4,6 

/ 

49 

0,1,4,6 

<*N>  - 

0,7 

+ 

lb 

0,1,4,6 

J 

33 

0,1,2 

S 

50 

0,1,2 

<*S>  - 

0,7 

0  =  Any  Terminal 

1  =  Any  Character 

2  ==  Any  Letter 

3  =  Any  Digit 


4  =  Any  Special  Character 

5  =  Any  Relational  Operator 

6  =  Any  Algebraic  Operator 

7  =  Any  Non-Character 


fewer  meta- characters  and,  as  such,  require  fewer  sharps.  Although  it  is 
very  easy  to  insert  the  necessary  sharps,  it  may  be  desirable  to  make  a 
preliminary  run  through  the  TWINKLE  translator  alone  to  isolate  what  trouble 
spots  there  may  be. 

An  alternative  method  for  indicating  a  character  in  the  syntax 
which  avoids  the  details  of  the  sharp,  and  which  provides  for  a  more 
readable  syntax,  consists  of  writing  down  the  English  word  or  phrase  which 
identifies  the  character  in  question.  Thus,  in  production  (l)  above, 
SEMICOLONS  is  used  in  place  of  the  equally  acceptable  "#;".  While  this 
form  is  not  available  for  all  of  the  special  characters,  it  proves  quite 
useful  in  practice.  A  complete  list  of  these  alternatives  is  given  in 
the  TWINKLE  syntax  (see  Appendix  B). 
2.1.1.2  Special  Words 

Many  times  it  is  convenient  to  consider  a  group  of  letters  and 
digits  as  being,  conceptually,  a  single  terminal.  Thus,  in  languages  of 
the  ALGOL  family,  the  letter  strings  BEGIN  and  END  are  each  taken  as 
single  terminals.   This  approach  has  an  advantage  in  the  milieu  of  the 
TWS  in  that  these  conceptual  units,  or  special  words,  are  compiled  rela- 
tively quickly  by  the  scanner  as  opposed  to  the  more  laborious  and  time 
consuming  letter  by  letter  compilation  through  the  syntax  and  semantics. 

Any  string  of  letters  and  digits  which  begins  with  a  letter  may 
be  used  as  a  special  word.   It  must  not  have  embedded  blanks,  and  the 
character  immediately  after  it  must  not  be  alphanumeric.  As  with  characters, 
a  special  word  must  be  prefixed  by  a  sharp  in  the  syntax  if  it  would 
otherwise  be  of  special  significance  to  the  TWINKLE  translator.   Since 
there  are  well  over  one  hundred  such  words  in  TWINKLE  (see  Appendix  A), 


it  is  safest  to  use  sharps  literally.   Again,  there  is  a  divergence  of  TWINKLE 
at  this  point  from  BNF  and  TBNF  which  is  easily  overcome. 
2.1.1.3  Character  Mode  Terminals 

While  the  special  word  is  often  the  better  way  of  entering 
alphanumeric  information,  there  are  times  when  character  by  character 
input  is  actually  preferable.   For  example,  the  parsing  of  FORTRAN  and 
B-5500  ALGOL  FORMAT  statements  is  simplified  if  done  in  the  character  mode. 
More  generally,  any  time  there  is  an  abundance  of  single  character  signifi- 
cance in  a  syntactic  entity,  it  is  better  parsed  and  more  compactly 
described  in  the  character  mode. 

If  the  sequence  of  characters  to  be  dealt  with  consists  entirely 
of  digits,  it  may  be  written  into  the  syntax  directly  because  an  unadorned 
number  has  no  special  significance  to  the  TWINKLE  translator.   If,  however,  a 
more  general  sequence  must  be  handled,  the  sequence  must  be  preceded  by  the 
word  ALPHA,  which  indicates  to  TWINKLE  that  it  must  consider  the  following 
sequence  of  characters  specially.   Since  ALPHA  is  a  bit  long,  it  behooves  one  to 
provide  a  means  of  keeping  its  use  to  a  minimum.   To  this  end,  the  construct, 

[ALPHA  A  /  ALPHA  B  /  ALPHA  C  /  ...  /  ALPHA  2]    , 

is  equivalent  to  the  more  compact  form, 

ALPHA  [A  /  B  /  C  /  . . .  /  Z] 

Another,  more  obscure,  method  of  specifying  alphanumeric 
characters  (or,  in  fact,  any  of  the  Burroughs  B-5500  characters)  is  the 
code  construct  which  is  based  on  the  internal  binary  representations  of 
the  various  characters.   This  form  of  character  representation  is  a 
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carry  over  from  TBNF  where  it  was  adopted  primarily  "because  the  question 
mark  is  not  a  valid  character  on  punched  cards  in  the  B-5500  system.   It 
consists  of  the  word  CODE  followed  by  an  integer  between  zero  and  sixty- 
three  which  is  the  internal  code  of  the  character  being  indicated. 
2.1.1.U  Meta-Terminals 

Because  of  the  advantages  attendant  to  allowing  the  scanner  to 
perform  a  certain  amount  of  simple  syntactic  analysis  immediately  on  the 
input  string  (as,  for  example,  in  the  recognition  of  special  words), 
the  TWS  scanner  also  recognizes  members  of  three  special  classes  of 
terminals:   identifiers,  numbers,  and  strings.   These  meta-terminals  are 
represented  in  the  syntax  by  the  symbols  <*I>,  <*N>,  and  <*S>,  respectively. 
In  an  English-like  syntax,  they  may  be  represented  by  IDENTIFIER  (or 
IDENTIFIERS),  NUMBER  (or  NUMBERS),  and  STRING  (or  STRINGS).  An  identifier 
is  any  sequence  of  alphanumeric  characters  beginning  with  a  letter, 
provided  the  sequence  is  not  a  special  word  of  the  language.  A  string 
is  any  sequence  of  characters  (excluding  the  quote)  enclosed  in  quotes. 
A  discussion  of  how  the  scanner  handles  these  items  has  been  given  by 
Machado  [lo]  • 

In  addition  to  these  three  meta-terminals,  TWINKLE  allows  for 
the  syntactic  specification  of  up  to  twenty  other  meta-terminal  symbol 
classes.   In  the  syntax,  these  are  represented  by  the  symbol  <*n>  where 
n  is  a  digit  between  four  and  twenty-three  and  identifies  the  meta- 
terminal.  A  special  scanner  is  necessary  to  take  advantage  of  this 
facility. 
2.1.1.5  Blanks 

Blanks  are  specified  in  the  syntax  by  the  word  BLANK.  A  blank 
can  only  be  scanned  in  the  character  mode. 
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2.1.2  Nonterminals 

Nonterminals  are  specified  in  TWINKLE  as  strings  of  characters, 
called  nonterminal  names,  enclosed  in  either  angle  brackets  or  quotes 

(<  >  or  "  "  ).   For  obvious  reasons  the  nonterminal  name  may 

not  include  either  angle  brackets  or  quotes.   Furthermore,  any  blanks 
which  appear  in  the  nonterminal  name  are  disregarded.   Thus,  the  nonter- 
minals, <PLOUGHS  HARE>  and  <PLOUGH  SHARE>,  are  treated  identically.   In 
the  BNF  or  TBNF  output  resulting  from  a  TWINKLE  translation,  the  blanks 
in  nonterminal  names  displayed  are,  in  fact,  removed.   To  retain  a 
modicum  of  readability  in  this  compact  form  it  is  advisable  to  hyphenate 
multi-word  nonterminal  names;  for  example,  use  <TYPED-PROCEDURE-DECIARA.TlON> 
in  place  of  <TYPED  PROCEDURE  DECLARATIONS 

The  first  nonterminal  to  appear  in  the  syntax  (i.e.,  the  non- 
terminal on  the  left  hand  side  of  the  first  production),  is  the  unique 
objective  symbol  or  program  symbol  of  the  language.  Any  string  of 
terminal  symbols  which  may  be  reduced  to  this  nonterminal  is  a  program 
in  the  language. 

In  addition  to  the  nonterminals  which  are  explicitly  defined  by 
the  language  designer,  nonterminals  are  introduced  by  TWINKLE  in  order  to 
implement  lists  and  to  execute  some  of  the  grammar  transformations  discussed 
in  Chapter  k.      These  nonterminals  are  distinguished  by  the  fact  that  they 
all  have  one  or  more  blanks  in  their  names  after  translation. 

.  . 3  Any  Symbols 

In  BNF,  alternatives  must  be  written  out  explicitly.   Thus,  to 
•ify  a  nonterminal,  say  <LETTER>,  which  is  any  of  the  twenty- six  letters 
of  the  alphabet,  one  must  write-- 
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<LETTER>  ::=A/B/C/.../X/Y/Z 

Trout,  in  TBNF,  introduced  the  pseudo-nonterminal,  <ANY>,  which  stands  for 
any  terminal  symbol.   If  not  all  terminals  are  to  be  indicated,  the 
exceptions,  if  small  in  number,  may  follow  the  pseudo-nonterminal — each 
preceded  by  the  special  word,  BUT.  For  example,  any  terminals  except 
BEGIN  and  END  may  be  written: 

<ANY>  BUT  #BEGIN  BUT  #END 


This  construct  has  been  used  primarily  in  error  recovery  in  TBNF  languages. 

In  TWINKLE,  the  any  symbol  has  been  generalized  and  has  become 
a  powerful  programming  tool.   The  syntax  of  <ANY  SYMBOL>  is  shown  below: 

(  #terminal 
Character 
#letter 

#DIGIT 
#ANY  /  #S FECIAL  #CHARACTER 

#RELATIONAL  #OPERATOR 
#ALGEBRAIC  #OPERATOR 

#NONCHARACTER 
\  <^i\TriT\iniTr'DMTi\Tfl  t/s  * 


LIST   OF    {#BUT  <TERMINAL>} 


) 


X 


#BUT     #[LIST   OF  <TERMINAL>S   SEP(     #/  }#  ] 


^ 


J 


V_ 


'<NONTERMINAL> 
v        


EXCEPTION  LIST 


BASE 


Use  has  been  made  of  a  rather  simple  two-dimensional  extension  of  TWINKLE: 
square  brackets  have  been  replaced  by  vertical  braces  with  the  alternatives 
occupying  one  line  each;  the  Greek  letter  'V  is  used  instead  of  the  special 
word,  LAMBDA. 

The  terminals  in  each  of  the  bases,  except  for  <NONTERMINAL>,  are 
shown  in  Table  I  (page  8).   The  <NONTERMINAL>  base  is  unique  in  that,  first, 
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the  elements  that  it  contains  depend  upon  the  actual  nonterminal  symbol 
used  and,  second,  they  are  not  restricted  to  terminals  but  include  all 
of  the  alternative  definitions  of  the  nonterminal.  Any  terminals  which 
are  in  the  base,  but  "which  are  not  desired,  may  be  written  in  the  excep- 
tion list  following  the  <ANY  SYMBOL>.  The  TBNF  form  of  the  exception  list 
is  still  accepted  by  TWINKLE  but,  as  with  the  ALPHA  list,  it  is  possible 
to  use  only  one  BUT  and  enclose  the  terminals  of  the  exception  list  in 
square  brackets  immediately  following  it.   Thus,  in  place  of 

BUT  #BEGIN  BUT  #ENL  BUT  #LEFT  BUT  #RIGHT   , 
one  may  write 

BUT  [#BEGIN  /  #END  /  #LEFT  /  #RIGHT] 

2.1.4  Square  Brackets 

In  English,  clauses  are  separated  at  one  level  by  commas  and 
at  a  higher  level  by  semicolons.  Beyond  this  either  more  than  one  sentence 
is  used  or  the  clause  separation  must  be  done  by  the  reader  from  context. 
Even  this,  however,  does  not  prevent  ambiguity  beyond  four  levels  or  so.  A 
language  such  as  TWINKLE,  in  which  it  is  necessary  to  indicate  clause 
nesting  to  an  arbitrary  level,  must  have  a  more  powerful  mechanism 
available. 

nee  the  semicomma  and  the  demisemicolon  do  not  yet  exist,  it 
decided  that  clauses  and  other  such  ensembles,  which  are  intended  as 
.ngle  syntactic  entities,  be  enclosed  in  square  brackets.   Two  examples  of 
•  e  already  been  encountered:   the  terminal  list  following  ALPHA, 

.1st  following  BUT.   Beyond  these  the  square  brackets  find 
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several  other  uses;  whenever  one  or  more  symbols,  or  groups  of  symbols, 
appear  at  one  spot  in  a  production  they  may  he  enclosed  in  square  brackets, 
Thus,  the  productions, 

AN  <ANY  SYMBOL>  CONSISTS  OF  #ANY  #TERMINAL; 
AN  <ANY  SYMBOL>  CONSISTS  OF  #ANY  #CHARACTER; 
AN  <ANY  SYMBOL>  CONSISTS  OF  #ANY  #LETTER    , 

may  be  written  more  compactly  as 

AN  <ANY  SYMBOL>  CONSISTS  OF  #ANY  FOLLOWED  BY  [^TERMINAL  OR 
#CRARACTER  OR  #LETTER]  . 

For  purposes  of  adding  semantic  symbols,  which  will  be  discussed  later, 
the  special  word,ANY,  and  the  bracket  construct,  taken  as  a  whole,  are 
considered  to  be  at  level  zero  of  the  production,  while  the  special 
words;  TERMINAL,  CHARACTER,  and  LETTER,  are  considered  to  be  at  level  one. 

Alternatively,  an  entire  production  may  be  nested  in  square 
brackets  and  one  may  write- - 


AN  <ANY  SYMBOL>  CONSISTS  OF  #ANY  FOLLOWED  BY  AN  [<ANY  BASE> 

CO 

WHICH  IS  DEFINED  TO  BE  #TERMINAL  OR  #CHARACTER  OR  #LETTER]   . 


Note  that  although  all  previous  forms  of  arrow  are  still  valid  in  the 
nested  production,  it  is  also  permissible  to  include  the  special  word, 
WHICH,  so  that  the  construct  will  look  more  like  an  English  clause.  When 
a  nonterminal,  such  as  <ANY  BASE>,  is  defined  in  a  nested  production  it 
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may  then  appear  anywhere  else  in  the  syntax  just  as  if  it  had  been  de- 
fined in  the  usual  manner.  There  are,  however,  some  precautions  to  be 
ta'^en  with  nested  productions.   These  stem  from  the  fact  that  the  non- 
terminal so  defined  may  have  additional  definitions  elsewhere  in  the 
syntax.   In  this  case  the  nonterminal  represents  the  totality  of  its 
alternative  definitions,  except  when  it  appears  on  the  left  hand  side 
of  a  nested  production  in  which  case  it  represents  only  those  definitions 
which  appear  on  the  right  hand  side  of  the  same  nested  production.  To 
illustrate  this,  suppose  that  in  addition  to  the  production  above,  in 
which  <ANY  BASE>  is  defined,  one  also  has  the  production: 


A  <SOME  SYMBOL>  CONSISTS  OF  #SOME  FOLLOWED  BY  AN 

(5) 
[<ANY  BASE>  WHICH  IS  #DIGIT  OR  #DIGITS] 


The  two  productions  (k)    and  (5)  are  then  equivalent  to  the  BNF  productions: 

<ANY  SYMB0L>  : : =  #ANY  <ANY  BASE  1>     ; 

<SOME  SYMBOL>  :  :  -  #SOME  <ANY  BASE  2>      ; 

<ANY  BASE>  :  :  =  <ANY  BASE  1>  /  <ANY  BASE  2>     ; 

<ANY  BASE  1>  :  :  =  ^TERMINAL  /  #LETTER  /  #CHARACTER     ; 

<ANY  BASE  2>  : : =  #  DIGIT  /  #DIGITS 

The  square  bracket  construct  may  also  be  applied  to  a  single 
string  of  symbols  to  indicate  that  the  string  is  to  be  taken  as  a  unit 
itself.  This  is  useful  in  constructs  such  as  the  maybe  symbol,  enclosures, 
.  lists  described  below. 
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2.1.5  Maybe  Symbols 

Frequently  a  syntactic  structure  has  one  or  more  substructures 
which  may  be  omitted  without  syntactic  error.  Thus,  for  example,  in  ALGOL 
a  list  of  labels  preceding  a  statement  is  optional.  Many  other  examples  may 
be  found  in  algorithmic  languages;  several  may  be  found  in  TWINKLE, 
itself.   To  make  the  specification  of  such  structures  as  easy  as  possible, 
Trout  [h]    adopted  the  Brooker  and  Morris  question  mark  [ll] --changing  it,  in 
the  process,  into  an  ampersand  because  the  question  mark  is  an  illegal  char- 
acter on  B-5500  cards.   In  TWINKLE,  either  an  ampersand  or  a  question  mark  may 
be  placed  after  a  symbol  (or  group  of  symbols  enclosed  in  square  brackets)  to 
indicate  that  it  is  optional.  The  English-like  form  of  this  construct  con- 
sists of  preceding  the  optional  symbol  by  the  special  word  phrase,  POSSIBLY 
ONE.   This  form  is  more  general,  in  that  it  may  be  applied  directly  to  lists 
and  enclosures;  whereas,  they  must  be  enclosed  in  brackets  when  followed  by  a 
question  mark  or  ampersand. 

An  example  of  the  English  form  of  <MA.YBE  SYMBOL>  follows.  The 
production, 

AN  <ANY  SYMBOL>  CONSISTS  OF  AN  <ANY  PART>  FOLLOWED  BY 

POSSIBLY  ONE  <EXCEPTION  LIST>    , 
is  equivalent  to  the  two  BNF  productions: 

<ANY  SYMBOL>  : : -  <ANY  PART>   ; 

<ANY  SYMBOL>  :  :  =  <ANY  PART>  <EXCEPTION  LIST> 

Under  more  complex  conditions,  the  maybe  symbol  can  account  for  a  considerable 
increase  in  readability  of  the  syntax. 

2-1.6  Enclosures 

Another  very  common  construct  in  computer  languages  is  that  in  which 
some  structure,  such  as  a  list  of  subscripts,  is  enclosed  in  delimiters,  such 


as  parentheses.   The  delimiters  may  be  different:  e.g.,  the  special  words, 
BEGIN  and  END,  which  bracket  compound  statements  in  ALGOL;  they  may  be  different 
but  very  closely  related:  e.g.,  the  left  and  right  parentheses  which  enclose 
subscript  lists  in  FORTRAN  and  PL1;  they  may  be  identical:   e.g.,  quotes  which 
delimit  strings  in  ALGOL  or  periods  which  enclose  logical  operators  in  some 
dialects  of  FORTRAN.   Corresponding  to  these  possibilities  there  are  three 
forms  of  enclosure.  The  general  representative  of  the  first  form  may  be 
symbolized  as: 

<SYMBOL>  #ENCLOSED  #IN  <SYMBOL>  #AND  <SYMBOL> 

where  <SYMBOL>  represents  any  basic  TWINKLE  symbol  or  group  of  symbols  en- 
closed in  brackets.   The  latter  two  symbols,  if  not  enclosed  in  brackets,  may 
not  be  enclosure  symbols  themselves.   Using  this  construct  and  the  list  symbol 
discussed  below  a  compound  statement  in  ALGOL  may  be  defined  by  the  very  clear 
production: 

A  <COMPOUND  STATEMENT>  IS  DEFINED  TO  BE  A  POSSIBLY  EMPTY  LIST  OF 
<STATEMENT>S  SEPARATED  BY  SEMICOLONS  ENCLOSED  IN  #BEGIN  AND  #ENDj   . 

The  second  form  of  enclosure  actually  applies  to  only  three  sets  of  characters 
in  the  Burroughs  character  set:  parentheses,  square  brackets,  and  angle  brack- 
ets.  It  may  be  symbolized,  using  the  two  dimensional  bracket  construct  de- 
scribed earlier,  as: 

C\ ^PARENTHESES     ] 
<SYMBOL>  #ENCLOSED  #IN    {   #ANGLE  #BRACKETS  f 

(  #SQUARE  #BRACKETSJ 

Finally,  the  third  form  of  enclosure  symbol  is  simply: 

<SYMBOL>  #ENCL0SED  #IN  <SYMBOL> 

word,  S,  may  be  added  to  make  the  second  symbol  plural. 
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2.1.7  Unordered  List 

The  unordered  list  provides  a  means  of  indicating  that  a  group  of 
items  may  appear  in  any  order.   One  very  simple  example  of  the  use  of  this  is 
the  PL1  iterated  DO  loop.   The  leading  statement  may  have  an  initial  value, 
increment,  and  final  value  for  the  control  variable;  the  increment  and 
final  value  may  appear  in  either  order.   Symbolically  the  unordered  list  has 
the  form: 

#UNORDERED  #LIST  #0F  [<SYMBOL>#AND<SYMBOL>-  •  •  #AND  <SmBOL>]    ; 
or 

[<SYMBOL>  #AND  <SYMBOL>  •  •  •  #AND  <SYMBOL>]  #IN  #ANY  #ORDER 

2.1.8  Precedence  Structures 

The  precedence  structure  was  introduced  in  TBNF  to  allow  for  the 
specification  of  operator  precedence  in  a  BNF  environment.   Since  the  prece- 
dence structure  does  not  lend  itself  readily  to  a  simple  English  alternative, 
its  syntax  has  not  been  expanded  from  the  TBKF  version.  A  precedence  struc- 
ture consists  of:  the  special  word,  OPERATOR,  followed  by  a  list  of  precedence 
groups  enclosed  in  square  brackets;  followed  by  the  special  word,  ON;  and, 
finally,  by  the  operand  on  which  the  precedence  is  based.   Each  precedence 
group  consists  of  a  list  of  symbols,  the  operators,  followed  by  the  special 
word,  PRECEDENCE,  and  a  pair  of  integers  separated  by  a  comma  enclosed  in  paren- 
theses.  The  integers  indicate  the  precedence  of  the  preceding  operators  in 
the  stack  and  in  the  input  stream,  respectively.   Succeeding  precedence  groups 
are  separated  from  one  another  by  slashes.  The  following  is  an  example  of 
the  use  of  a  precedence  structure : 

ARITHMETIC  EXPRESSION>  ::  = 

OPERATOR[#f  #-  PRECEDENCE (1,1)/  #/  #X  PRECEDENCE^, 2)]  ON  <PRIMARY> 
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2.1.9  Lists 

The  list  is  one  of  the  most  useful  of  the  TWINKLE  constructs.   Con- 
sequently it  occurs  in  a  wide  variety  of  English-like  and  symbolic  forms.   To 
indicate  a  simple  list  without  separators,  the  right  square  bracket  of  a  nested 
production  or  square  bracket  construct  may  be  followed  by  an  asterisk  or  by  a 
plus  sign.   The  asterisk  denotes  a  possibly  empty  list  while  the  plus  sign 
denotes  a  list  that  must  have  at  least  one  element. 

In  BNF,  lists  are  usually  formed  either  by  left  recursive  productions- 
such  as : 

<A>  :  :  =  <e>  /  <a>  <B>   ; 

or  by  right  recursive  productions  such  as: 

<A>  : : =  <B>  /  <B>  <A> 

This  underlying  structure  is  masked  by  the  simplicity  of  the  TWINKLE  constructs 
but  may  be  made  explicit,  if  desired,  by  the  insertion  of  the  qualifying  spe- 
cial word,  OPEN,  for  left  recursion  or  CLOSE,  for  right  recursion  between  the 
right  square  bracket  and  the  asterisk.   If  no  qualifier  is  present,  left  re- 
cursion is  implied. 

The  syntax  of  list  structures  allowing  for  separators  is  shown  in 
figure  1.  As  indicated  it  consists  of  five  portions:   head,  type,  base,  sepa- 
rator, and  tail.   Only  the  type  and  base  are,  necessarily,  nonempty  but  at  least 
one  of  the  head  and  tail  must  be  empty.   The  functions  of  these  various  com- 
ponents are  discussed  below. 
2.1.9.1  Head 

In  the  absence  of  the  list  tail,  the  list  head  determines 
whether  the  list  is  left  or  right  recursive.   If  it  is 
empty  (the  1      1  word,  REDUCED,  or  the  phrase,  LEFT  RECURSIVE), 
.1st  is  left  recursive.   If  it  is  R,  EXPANDED,  or  RIGHT 
::;  right  recursive. 


21 


O 
•P 
03 
U 
d 

0) 

-P 
K) 
•H 


O 
05 

t 


CD 

H 


2.1.9-2  Type 

Lists  may  be  either  possibly  empty  or  nonempty ,    as  noted 
above.   It  is  the  function  of  the  list  type,  which 
may  not  be  empty,  to  determine  this  characteristic.  A  non- 
empty list  is  indicated  by  the  list  types :  L,  LIST,  STRING, 
SEQUENCE,  NONEMPTY  STRING,  NONEMPTY  LIST,  and  NONEMPTY 
SEQUENCE.   For  a  possibly  empty  list,  the  available 
types  are  :  EL,  KLEENE,  KLEENE  STAR,  POSSIBLY  EMPTY  LIST, 
POSSIBLY  EMPTY  STRING,  and  POSSIBLY  EMPTY  SEQUENCE.   To 
improve  readability,  the  list  type  may  be  followed  by 
the  special  word,  OF.   If  the  list  type  is  either 
STRING  or  KLEENE,  OF  is  necessary  to  avoid  syntactic 
ambiguity. 

2.I.9.3  Base 

The  base  may  be  a  single  symbol  or  group  of  symbols 
enclosed  in  square  brackets.   It  must  not  be  a  list 
itself  and  is  considered  to  be  nested  one  level  deeper 
than  the  list  of  which  it  is  the  base.  An  S  may  follow 
the  base,  in  some  cases,  to  indicate  its  plural  character 
in  the  grammatical  structure  of  the  list.   In  addition, 
phrases  which  may  be  used  as  character  terminals 
all  have  plural  forms  which  may  be  used  profitably  here. 

•  .j.h     Separator 

The  power  of  the  list  construct  is  greatly  enhanced 
by  the  possibility  of  specifying  a  separator.  Like 
the  base,  the  separator  may  be  either  a  single  symbol 

jp  of  symbols  enclosed  in  square  brackets.  The 
•irator,         basi  ,    coni  LderecJ  bo  be  at  the  n^xt 
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higher  bracket  nesting  level  from  that  of  the  list,  itself. 
The  plural  forms  valid  in  the  base  are  also  valid  in  the 
separator.  The  appearance  of  the  separator  between 
successive  base  items  is  either  required  or  optional- 
according  as  the  separator  type  is  definite  or 
questionable.  Definite  separator  types  are  indicated 
by  SEP,  SEPARATOR,  and  SEPARATED  BY;  questionable 
separator  types  are  indicated  by  Q,,  and  by  the  special 
word,  POSSIBLY,  followed  by  any  one  of  the  definite 
separator  types. 

2.I.9.5  Tail 

In  the  absence  of  a  list  head,  the  tail  determines 
"whether  the  list  takes  the  left  recursive  or  right 
recursive  form.   If  it  is  empty,  or  the  special  word, 
CLOSE,  the  list  is  left  recursive.   If  it  is  the 
special  word,  OPEN,  the  list  is  right  recursive. 
Note  once  again  that  either  the  tail  or  the  head  must 
be  empty  in  any  list  structure. 

The  examples  below  illustrate  the  various  aspects 
of  the  list  structure: 

A  <SYNTACTIC  DESCRIPTION  CONSISTS  OF  A  POSSIBLY 
EMPTY  LIST  OF  <PRODUCTION>S  SEPARATED 
BY  SEMICOLONS; 

ARITHMETIC  EXPRESSION  ::=  LIST  [LIST  <PRIMARY> 
SEP  [#*  /#/]]  SEP  [#+/  #-]; 
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<STATEMENT>  :  :=  [<IABEL>  #:]  *  <UNLABELED  STATEMENTS 

AN  <ANY  MSE>  CONSISTS  OF  A  LEFT  RECURSIVE  LIST  OF 
<TERMINAL>S  POSSIBLY  SEPARATED  BY  SLASHES 
ENCLOSED  IN  SQUARE  BRACKETS; 

2.1.10  Seeded  Lists 

Any  of  the  list  structures,  the  syntax  for  which  appears  in  figure  1 
above,  becomes  a  seeded  list  when  followed  by  a  list  seed.  The  syntax  of  the 
list  seed  is 


#STARTING  ~ 
#BEGINNING_ 


} 


#WITH  <SYMB0L>   , 


where  <SYMB0L>  may  be  any  TWINKLE  symbol,  or  group  of  symbols,  enclosed  in 
square  brackets,  with  the  exception  of  enclosures  and  maybe  symbols. 

The  seed  list  may  be  used  to  indicate  that  the  first  element  of  a 
particular  list  is  distinguished  in  some  way  from  the  rest.  For  example, 
the  syntax  of  an  ALGOL  block  may  be  written: 

A  <BL0CK>  CONSISTS  OF  A  POSSIBLY  EMPTY  LIST  OF  <STATEMENT>S 
SEPARATED  BY  SEMICOLONS  STARTING  WITH  A  POSSIBLY  EMPTY 
LIST  OF  <DECLARATION>S  SEPARATED  BY  SEMICOLONS  ENCLOSED 
IN  #BEGIN  AND  #END 

[ote  that,  since  the  list  seed  may  not  be  an  enclosure,  the  enclosure  operator 
applies  to  the  entire  seeded  list  and  not  simply  to  the  list  of  <DECLARATION>S . 
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2.2  Semantic  Symbols 

The  TWINKLE  symbols  and  constructs  described  up  to  this  point  may 
be  used  in  the  syntactic  specification  of  a  language.  A  compiler,  however, 
must  be  more  than  simply  a  recognizer  for  a  language.   It  must  assign  appro- 
priate meanings  (e.g.,  in  the  form  of  equivalent  machine  code)  to  the  various 
syntactic  entities  that  it  recognizes  from  the  input  stream.  These  meanings, 
taken  as  a  whole,  make  up  the  semantic  description  of  the  language  or,  more 
simply,  the  semantics  of  the  language.   In  the  TWS,  the  semantics  is  written 
in  the  Illinois  Semantics  Language  (ISL),  a  complete  description  of  which  is 
provided  by  Machado  [10  ]  •   For  the  purposes  of  this  discussion,  it  suffices 
to  consider  the  ISL  semantic  description  as  a  number  of  individual  semantic 
blocks,  each  of  which  is  associated  with  a  semantic  name  through  which  it  may 
be  accessed  by  the  parser.   Before  describing  the  manner  in  which  the  parser 
is  directed  to  initiate  a  semantic  block,  it  is  necessary  to  consider  the  pos- 
sible results  of  the  execution  of  a  semantic  block. 

2.2.1  Actions  and  Tests 

Based  on  their  effect  on  the  parser,  semantic  blocks  may  be  divided 
into  two  groups:   semantic  actions  and  semantic  tests.  Actions  have  no  direct 
effect  on  the  parser  and  are  used  primarily  for  such  functions  as  table  cre- 
ation, code  emission,  etc  Tests,  on  the  other  hand,  are  actually  more  of  a 
syntactic  character  than  a  strictly  semantic  character.  Thus,  a  test  is 
called  by  the  parser  when  the  nature  of  a  particular  entity  is  syntactically 
undeterminable  and  requires  investigation  on  a  higher  level.  For  example, 
in  an  ALGOL  assignment  statement  a  boolean  variable  must  be  assigned  the 
value  of  a  boolean  expression  while  an  integer  or  real  variable  must  be 
assigned  the  value  of  an  arithmetic  expression.   Since  the  declaration  in 
which  the  type  of  the  variable  in  question  was  determined  may  precede  its 
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usage  by  an  arbitrary  amount,  and  since  an  arithmetic  expression  and  a 
boolean  expression  may,  in  general,  be  identical  for  arbitrarily  many  symbols, 
the  parser  is  unable  to  determine  whether  an  arithmetic  or  boolean  assignment 
is  being  made.   The  question  is  resolved  by  calling  a  test  which  compares 
the  variable  with  tables  made  when  the  declarations  were  recognized.   The 
result  of  this  comparison  is  communicated  to  the  parser  which  then  is  able 
to  proceed  correctly  with  the  parse. 

Communication  between  test  and  parser  is  by  means  of  the  globally 
declared  boolean  variable,  SEMANTICTEST.   If  the  value  of  SEMANTICTEST  after 
the  execution  of  the  test  is  true,  the  parser  continues  along  the 
indicated  branch  of  the  parsing  tree.   Otherwise  the  parser  abandons  this 
branch  and  must  decide  among  the  remaining  branches,  possibly  invoking  further 
tests  in  the  process.   It  is  important,  therefore,  that  each  block,  which  may 
be  called  as  a  test,  set  SEMANTICTEST  at  some  point  in  its  execution.   If 
this  is  not  done,  the  parser  -will  determine  its  future  course  of  action 
from  the  previous  value  of  SEMANTICTEST  with  the  attendant  possibility  of 
an  erroneous  parse.   Since  any  block  may  be  called,  both  as  an  action  and  as 
a  test,  at  different  times  during  the  parse, it  is  permissible  for  an  action 
to  set  SEMANTICTEST   although  the  variable  is  disregarded  under  these  circum- 
stances. 

An  indication  to  the  parser  of  the  points  in  the  syntactic  recogni- 
tion at  which  a  particular  action  or  test  must  be  involved  is  given  by  placing 
semantic  call  symbols  at  appropriate  points  in  the  syntax.  These  calls  may 
have  any  of  the  three  forms  described  below. 

'  .  .'-   Simple  Calls 

'nple  action  (test)  calls  consist  of  the  special  symbols,  "^S"("@T"), 
olloved  by  the  name  of  the  action  (test)  being  called.  Any  string  of  digits 
*  alphanumeric  characters  beginning  with  a  letter  may  be  used  as  a  name. 
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A  particular  semantic  block  may  be  called  from  as  many  places  in  the  syntax 
as  desired  and  may  be  called  as  a  test  of  one  point  while  being  called  as  an 
action  at  another  point.   Several  forms  of  the  simple  call  linger  from  earlier 
versions  of  the  TWS.  Thus,  in  addition  to  "@S",  an  action  name  may  be  pre- 
ceded either  by  "@Q"  or  "#",  and  a  test  name  may  be  preceded  by  "#"  and 
enclosed  in  either  quotes  or  angle  brackets.  When  "#"  is  used  in  an  action 
call,  the  action  name  must  be  a  string  of  digits.  The  reason  for  this  is  that 
the  call  would  appear  to  be  a  special  word  if  the  action  name  were  to  begin 
with  a  letter. 

2.2.3  Declaration  Calls 

Any  of  the  simple  calls  (except  the  "#"  <action  name>  form)  may  be 
extended  into  a  declaration  call.  The  action  or  test  name  is  followed  by  a 
colon  and  then  a  description  of  the  action  or  test  in  ISL  code.   This  descrip- 
tion, or  declaration,  must  be  enclosed  either  in  square  brackets,  or  in  the 
special  words,  BEGIN  and  END.   Each  name  may  be  declared  no  more  than  once  in 
this  way,  although  such  a  declaration  is  not  necessary.  Any  name  so  declared 
may  be  used  in  the  syntax  in  simple  calls,  both  before  and  after  the  appearance 
of  the  declaration.  When  the  semantic  block  in  question  is  brief,  the  overall 
clarity  of  the  linguistic  description  may  be  considerably  enhanced  by  using  the 
declaration  call. 

2.2.U  Implicit  Calls 

When  a  block  is  of  such  a  nature  that  a  declaration  call  would  be 
appropriate,  and  yet  is  used  in  only  one  place,  it  is  clearly  not  necessary 
to  give  a  name  to  that  block.   Under  these  circumstances  the  name  and  colon 
in  the  declaration  call  may  be  omitted,  thereby  creating  an  implicit  call.  For 
each  implicit  call  in  the  syntax,  the  TWINKLE  translator  generates  a  unique  name 
through  which  the  relevant  block  of  code  may  be  referenced  by  the  ISL  translator. 
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2.2.3  Parameterized  Semantic  Calls 

Semantic  calls,  -with  the  exception  of  implicit  calls,  may  be  modified 
by  a  list  of  integer  constant  parameters  separated  by  commas  enclosed  in  paren- 
theses and  placed  immediately  following  the  action  or  test  name.  These  constants 
are  used  by  the  parser  to  set  a  group  of  global  variables  (the  array  row  PARAM) 
that  may  be  referenced  by  the  semantic  routine  when  it  is  called.   This  is 
frequently  very  useful  when  a  number  of  portions  of  the  syntax,  which  would 
otherwise  require  different  semantic  actions,  may  be  serviced  by  a  single, 
appropriately  parameterized,  action.   For  example,  in  recognizing  written  out 
characters,  TWINKLE  employs  a  single  semantic  action  whose  parameter  is  the 
internal  code  number  of  the  symbol  recognized. 

2.2.6  Bit  Actions  and  Tests 

Frequently,  a  semantic  action  involves  nothing  more  than  the  setting  of 
a  single  bit.  Similarly,  a  semantic  test  is  frequently  based  on  the  condition  of 
such  a  bit.  Calling  a  semantic  block  to  perform  these  manipulations  requires  a 
disproportionate  amount  of  overhead  and  it  was,  therefore,  considered  appropriate 
to  introduce  special  action  and  test  types  specifically  for  performing  bit  opera- 
tions.  The  syntax  of  the  bit  action  is: 

f#SET 

#g    #s    [#reset|   #bit  <bit  name> 

where  <BIT  NAME>  is  either  a  number,  identifier,  or  TWINKLE  special  word.   The  de- 
signated bit  is  correspondingly  either  set  or  reset.  The  syntax  for  the  bit  test 

r  x 

J#ON 


#§  #T  #BIT  <BIT  NAME>|#OFfJ 

Condition      Action 

The  test  is  true  if  the  designated  bit  is  in  the  condition  specified  (i.e.,  ON  or 

F).  The  default  condition  is  ON.   If  the  test  is  true  the  indicated  action  is 

the  designated  bit.   Up  to  kQ   different  bit  names  may  be  used  by  the  lan- 

These  are  assigned  by  the  TWINKLE  translator  to  the  hd   bits  of 

Le,  ACTIONBITS. 
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2.2.7  The  Tail 

In  most  languages  it  will  not  be  desirable  to  declare  each  block 
(implicitly  or  otherwise)  directly  in  the  syntax  specification.  Also,  all 
but  the  simplest  of  semantics  will  require  a  number  of  variables  and  procedures 
declared  globally  to  the  individual  semantic  blocks.  For  the  sake  of  complete- 
ness, these  global  declarations  and  undeclared  blocks  may  be  enclosed  between 
the  special  words,  BEGIN  and  END,  (thus  forming  the  semantic  tail)  and  appended 
to  the  syntax  specification.  This  tail  will  then  be  passed  directly  to  the 
ISL  translator  upon  completion  of  the  TWINKLE  translation.   In  this  way  a 
language  may  be  completely  processed  by  the  TWS  from  a  single  complete  specifi- 
cation of  the  language.   During  the  debugging  phase  of  the  language  development, 
it  is  more  natural  to  process  the  syntax  and  semantics  separately.  The 
details  of  coordinating  the  ISL  translator  with  the  rest  of  TWS  in  an 
independent  run  are  discussed  by  Machado  [lo] • 

2.2.8  Placement  of  Calls 

A  semantic  call  may  appear  anywhere  in  the  syntax  that  a  syntactic 
symbol  may  appear,  except  at  the  beginning  of  an  alternative.   Thus,  a  semantic 
call  may  not  appear  immediately  after  the  arrow  of  a  production,  the  left  square 
bracKet  of  a  square  bracket  construct,  or  the  separator  ("/"  or  OR)  of  a 
list  of  alternatives.   The  reason  for  this  is  that  a  semantic  call  cannot  be 
made  by  the  parser  until  it  has  determined  exactly  what  stage  the  parse  has 
reached.   Clearly  the  parser  cannot,  in  general,  determine  this  at  the 
beginning  of  an  alternative. 

Unfortunately,  there  is  a  good  deal  more  to  placing  semantic  calls 
than  simply  knowing  where  they  will  be  legal.  The  ideal  time  to  place  them 
would  be  after  the  FPL  form  (see  chapter  3  and  the  paper  by  Beals  [3  ])  had 
been  generated.   The  condition  of  the  stack  and  the  phase  of  the  parse 
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would  then  "be  known  explicitly.   It  is,  however,  fairly  straightforward  to 
place  them  directly  into  BNF  as  was  done  in  earlier  versions  of  the  TWS.   The 
problems  present  in  TWINKLE,  with  respect  to  call  placement,  arise  chiefly  from 
the  complex  structures  (lists,  enclosures,  etc.)  available  and  from  the  large 
amount  of  grammar  transformation  that  is  inherent  in  TWINKLE  translation. 
Thus,  virtually  all  of  the  TWINKLE  constructs  not  present  in  BNF  employ  some 
form  of  TWINKLE  generated  nonterminals  in  their  implementation.  Because  of 
this,  the  configuration  of  the  stack  at  the  moment  of  a  semantic  call  may  not 
be  easy  to  determine.   The  following  guidelines  will  be  helpful  in  creating 
and  placing  semantic  calls  to  achieve  a  given  end: 

1.  A  semantic  call  is  made  following  the  recognition  of  the  symbol 
or  construct  at  the  same  bracket  nesting  level  immediately 
preceding  its  occurrence  in  the  syntax.   For  example,  if  one 
writes 

<A>  : : =  LIST  <B>  SEP  <C>  @S1   , 
semantic  action  "1"  will  be  called  after  the  entire  list 
has  been  recognized  and  not  after  each  separator,  <C>.  The 
latter  effect  may  be  achieved  by 

<A>  :  :  =  LIST  <B>  SEP  [<C>  @Sl] 

2.  A  semantic  routine  should  not  reference  the  stack  for  symbols 
at  the  same  nesting  level  as  its  call — provided  that  the  call 
and  the  symbol  are  separated  by  one  of  the  non-BNF  TWINKLE 
constructs.   For  example,  in  the  TWINKLE  production, 

<A>  :  :=  <B>  <C>  LIST  <E>  <F>  <G>  @S  A   , 
the  semantic  action,  "A",  may  reliably  reference  the  nonterminals, 
<F>  and  <G>,  but  may  not  reference  the  nonterminals,  <B>  and  <C>, 

from  which  its  call  is  separated  by  the  list  construct. 
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3«  A  semantic  routine  should  not  reference  symbols  which  occur  at 
different  nesting  levels  from  its  call.  The  only  exception  to 
this  rule  is  the  case  in  which  a,  semantic  call  immediately  follows 
the  right  square  bracket  of  a  square  bracket  construct.  The  call 
is  then,  in  essence,  copied  onto  the  end  of  each  of  the  alternatives 
within  the  square  brackets. 
A  detailed  example  showing  the  placement  of  semantic  calls  in  a  TWINKLE 
grammar  for  a  subset  of  ALGOL  is  provided  by  Machado  [lo]« 

2.3  Null  and  Empty  Symbols 

Several  forms  of  context  analysis  which  are  performed  automatically 
by  the  TWS  must  be  provided  by  the  user  under  the  TBNF  system.  The  three 
special  words  (BACK,  AHEAD,  and  NOT),  which  are  used  in  TBNF  to  provide  con- 
textual information,  have  no  meaning  to  the  BNF  half  of  the  TWS.  Therefore, 
when  translating  into  BNF,  these  special  words  and  the  constructs  that  they 
herald  are  meaningless  to  TWINKLE  and  are  referred  to  as  null  symbols.   In 
addition  to  these  null  symbols,  TWINKLE  provides  two  forms  of  comments  which 
are  meaningless  and  therefore  qualify  as  null  symbols.  Any  string  of  symbols 
enclosed  in  parentheses,  the  left-most  parenthesis  of  which  is  not  preceded 
by  either  a  sharp  or  a  semantic  call,  constitutes  a  comment  and  is  deleted 
by  the  scanner.  Any  string  of  symbols  preceded  by  the  special  words,  COMMENT 
or  C,  and  not  including  the  symbols  [,],;,.,  or  the  special  words, BEGIN  and 
END,  also  constitutes  a  comment. 

An  empty  symbol  denotes  a  string  of  zero  length.   It  is  written  as 
either  one  of  the  special  words,  EMPTY  or  LAMBDA,  or  as  an  adjacent  pair  of 
left  and  right  nonterminal  parentheses  (i.e.,  <  >  or  "  ") . 
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3-   CONTROL  OF  THE  TWINKLE  TRANSLATION 

The  TWINKLE  translation  is  merely  the  first  step  in  a  chain  of  opera- 
tions undertaken  in  generating  a  compiler  for  a  language.   Control  options 
specified  in  the  TWINKLE  input  may  be  intended  for  use  in  a  later  phase  of 
the  TWS.  To  make  the  meaning  of  these  options  clear  a  brief  description  of 
the  entire  TWS  is  now  given. 

3«1  The  Translator  Writing  System 

Figure  2  presents  a  block  diagram  of  the  interrelations  between  the 
programs  which  make  up  the  Translator  Writing  System  when  creating  a  compiler 
for  a  language,  L.  As  indicated,  the  TWS  can  generate  either  a  recursive 
descent  compiler  or  a  deterministic  Floyd  production  compiler,  the  decision 
being  made  by  the  user  through  the  PARSER  control  card.   Consideration  will 
be  given  first  to  the  Floyd  production  section  of  the  TWS  which  comprises  the 
TWINKLE  translator,  the  ISL  translator  (ISLTRAN),  BNF2FPL,  FPL2PAR,  PAR2ALG 
and  finally,  the  ALGOL  compiler. 

A  unified  syntactic  and  semantic  description  of  L  is  provided  as 
input  to  the  TWINKLE  translator.  The  translator  extracts  the  syntactic  infor- 
mation which  it  transforms  into  BNF  and  places,  together  with  several  other 
tables,  it  in  a  disk  file  labelled  L/TABLESF.   Similarly,  the  semantic  portion 

the  input  is  placed  in  file,  L/ ACTIONS,  for  use  by  ISLTRAN.   The  TWINKLE 
translator  then  initiates  execution  of  both  BNF2FPL  and  ISLTRAN.  The  BNF 
syntax  of  L  is  transformed  by  BNF2FPL  into  Floyd  productions  (FPL)  which  are 
ilaced  in  L/FLOYDP  while  additional  tables  are  placed  in  L/TABLESF  and  the 
information  in  the  first  record  of  L/TABLESF  is  updated.  BNF2FPL 
.itiates  execution  of  FPL2PAR  which  transforms  the  FPL  syntax  from 
nto  a  stream  of  pseudo-orders  which  are  returned  to  L/TABLESF. 
itrol  information  in  the  first  record  is  updated. 
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At  this  point  a  small  digression  must  be  made  to  discuss  the  structure 
of  the  parser,  itself .  The  parser  consists  of  three  portions:   a  lookahead 
section  used  in  the  differentiation  of  Floyd  productions  by  analysis  of  input 
symbols  as  yet  unscanned;  a  section  for  filling  the  various  parsing  tables; 
and  a  section  which  actually  performs  the  parsing.  Each  of  these  sections  may 
be  either  interpretive,  operating  from  the  tables  in  L/TABLESF,  or  executable 
(i.e.,  a  self-contained  piece  of  ALGOL  code).  An  executable  section  must, 
clearly,  be  tailor-made  for  the  language,  L.  Therefore,  if  any  executable  sections 
are  requested,  FPL2PAR  initiates  the  execution  of  PAR2ALG,  passing  to  it  the 
requisite  information  in  L/TABLESF.   PAR2ALG  then  creates,  as  necessary,  L/LK, 
L/FILLTAB,  and  L/PARSER  for  executable  lookahead,  table  filling,  and  parsing, 
respectively. 

Meanwhile,  ISLTRAN  uses  the  semantic  information  in  L/ACTIONS  to 
create  a  package  of  ALGOL  routines  to  be  called  by  the  parser  at  strategic 
moments.  When  these  have  been  assembled  in  L/ALGSEM,  ISLTRAN  consults  the 
control  information  in  the  first  record  of  L/TABLESF  to  determine  if  any  execut- 
able sections  are  required.   If  none  is  needed,  ISLTRAN  initiates  an 
ALGOL  compilation  of  L/ALGSEM  merged  with  several  standard  pieces  of  code  from 
TWS/FILES.   If,  on  the  other  hand,  one  or  more  executable  sections  are  required 
for  the  compiler,  ISLTRAN  will  initiate  the  compilation  only  if  PAR2ALG 
has  been  completed;  otherwise,  ISLTRAN  terminates,  the  ALGOL  compilation  being 
initiated  by  PAR2ALG  upon  its  completion. 

The  srecond  half  of  the  TWS,  comprising  the  TWINKLE  translator,  ISLTRAN, 
TWST,  and  the  ALGOL  compiler,  is  involved  in  producing  a  recursive  descent 
impiler.  The  TWINKLE  translator  transforms  the  syntactic  portion  of  its  input 
BNF  which  it  places  in  L/SOURCE.  The  semantic  portion  is  collected  as 
ore  in  L/ACTIONS  and  passed  to  ISL  for  processing.   Upon  completion  ISLTRAN 
icecution  of  TWST  which  combines  the  information  in  L/SOURCE  and 
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L/ACTIONS  with  the  standard  basic  structure  contained  in  TWST/ SKELETON.   This 
is  returned  to  L/SOURCE  as  an  ALGOL  version  of  a  compiler  for  L  which  is  then 
sent  to  the  ALGOL  compiler  for  compilation—the  result  being  the  compiler  for  L. 

3»2  Control  Statements 

The  flow  of  control  described  above  cannot  be  wholly  automatic-  For 
example,  the  user  must  determine,  either  explicitly  or  implicitly,  whether  he 
wants  a  Floyd  production  or  a  recursive  descent  compiler.  Other  user-controlled 
decisions,  while  not  necessary,  are  often  desirable.  The  control  statements 
described  below  provide  a  large  measure  of  user  determined  control. 

3.2.1  Language  Name  Designation 

The  first  card  in  any  input  deck  to  the  TWS  must  be  the  language 
name  designation  card.   The  format  of  this  card  is : 

LANGUAGE  <LANGUAGE  NAME>; 

where  <LANGUAGE  NAME>  is  any  string  of  letters  and  digits  beginning  with  a 
letter.   These  characters,  or  the  first  seven  if  there  are  more,  are  used  as 
a  prefix  for  all  the  interlinking  and  output  files  generated  by  the  TWS, 
including  the  TWINKLE  translator. 

3.2.2  Print  Options 

The  print  control  statement  consists  of  the  special  word, PRINT, 
followed  by  a  colon,  followed  by  a  list  of  print  options  separated  by  commas, 
followed  by  a  semicolon.   The  options  available  are  defined  below. 

1.  TABLES  SIFESF:   causes  the  printing  of  a  table  displaying  the  sizes  and 
locations  of  all  of  the  tables  in  the  f ile, TABLESF • 

2.  TERMINALS  ALPHABETICALLY,  or  TRMALF:   causes  the  printing  of  an  alphabetic 
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list  of  all  of  the  special  -words  used  in  the  language.   If  BNF  is  being 
generated  then  the  list  includes  an  index  of  each  occurrence  of  the 
special  words  in  PROTAB. 

3.  TERMINALS  NUMERICALLY,  or  TRMNUM:   causes  the  printing  of  a  numerically 
ordered  list  of  all  of  the  special  words  used  in  the  language. 

h.      CHARACTERS ,  or  TRMCHR:   causes  the  printing  of  an  index  of  the  occurrences 
of  the  6k   characters  in  PROTAB. 

5-   TERMINALS:   is  equivalent  to  2,  3,  and  k   taken  together. 

6.   NONTERMINALS  ALPHABETICALLY,  or  NTALF:   causes  the  printing  of  an  alpha- 
betical list  of  all  of  the  nonterminals  used  in  the  language.   If  BNF  is 
generated,  the  list  includes  an  index  of  each  occurrence  of  the 
nonterminals  in  PROTAB- 

7-   NONTERMINALS  NUMERICALLY  or  NTNUM:   causes  the  printing  of  a  numerically 
ordered  list  of  all  of  the  nonterminals  used  in  the  language. 

.   NONTERMINALS:   is  equivalent  to  6  and  7  taken  together. 

9-   SYNTAX,  or  INPUT:   causes  the  printing  of  the  TWINKLE  input  as  it  is  read. 

0.  INDEX,  or  XREF,  or  CROSS  REFERENCE:   causes  the  printing  of  an  index  of 

occurrences  of  all  nonterminals,  terminals,  and  actions  in  the  syntax 
by  card  number. 

1.  AC!  IONS  ALPHABETICALLY,  or  ACTALF:   causes  the  printing  of  an  alphabetical 

all  of  the  semantic  actions  and  tests  used  Ln  the  language.   If 
I   generated,  the  list  includes  an  index  of  each  occurrence  of 
d  tests  in  PROTAB. 


37 

12.  ACTIONS  NUMERICALLY,  or  ACTNUM:   causes  the  printing  of  a  numerically 
ordered  list  of  all  of  the  semantic  actions  and  tests  used  in  the  language. 

13.  ACTIONS:   is  equivalent  tc  11  and  12  taken  together. 

Ik.      PROTAB:   is  the  name  of  the  table  into  which  TWINKLE  places  the  BNF 
equivalent  of  TWINKLE  syntax  in  the  input.   This  option  causes  the 
printing  of  this  table. 

15.  FLOYD:   BNF2FPL  transforms  PROTAB  into  a  set  of  Floyd  productions  in  the 
disk  file,  L/FLOYDP.   This  option  causes  the  printing  of  these  Floyd 
productions. 

16.  COMBINED  GROUPS:   causes  the  printing  of  the  components  of  all  of  the 
combined  groups  required  by  the  language.   For  a  discussion  on  the  use 
of  combined  groups,  see  the  paper  by  Beals  [  3  ] • 

17.  PARSER:   FPL2PAR  transforms  the  Floyd  productions  in  FLOYDP  into  a  stream 
of  pseudo-orders  which  make  up  the  parser.   This  option  causes  the 
printing  of  this  stream  of  pseudo-orders. 

18.  PATTERNS:   causes  the  printing  of  a  table  of  the  <ANY  SYMBOL>  patterns 
created  in  the  TWINKLE  translator  processing  of  L,  as  well  as  any 
additional  patterns  created  by  either  BNF2FPL  or  FPL2PAR. 

19-   STANDARD:   is  the  union  of  options  1,  5>  8,  9,    10,  13,  1^,  and  18. 

20.  DEBUGGING,  or  DEBUGN:   is  the  union  of  options  15,  l6  and  19,  i.e.,  of 
everything  but  option  17 • 

21.  EVERYTHING:   this  is  the  union  of  all  options. 

22.  NOTHING:   this  option,  when  used  by  itself,  inhibits  all  printing. 
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If  no  print  control  statement  appears,  the  print  options  are  set 
to  the  default  option,  STANDARD. 

3-2»3  The  Parser  Type  Option 

As  mentioned  several  times  above,  the  TWS  is  equipped  to  produce 
compilers  based  on  either  recursive  descent  or  Floyd  production  language  parsers. 
It  is  appropriate,  therefore,  to  have  a  control  statement  for  determining  -which 
is  to  be  generated.   The  relevant  control  statement  is  : 

<PARSER  TYPE>  PARSER; 
where  <PARSER  TYPE>  is  either  RECURSIVE  DESCENT  or  FLOYD  PRODUCTION. 

3-2.U  Zip  Control 

In  Burroughs  B-5500  ALGOL  it  is  possible  for  one  ALGOL  program 
to  initiate  execution  of  another  by  executing  a  zip  statement  (i.e.,  by 
zipping  to  the  other  program).   The  component  programs  of  the  TWS  use  the 
zip  statement  to  initiate  their  successors.   In  normal  operation  zipping 
continues  through  final  compilation  by  the  ALGOL  compiler.   Frequently,  a 
user  does  not  desire  execution  of  the  entire  TWS  but  may  wish,  for  example, 
to  check  just  the  syntax,  or  just  the  semantics,  of  the  input.   This  possibility 
is  allowed  for  in  the  TWS  by  the  zip  control  statements  which  are  listed  below: 

ZIP  TO  ISLj 
DONT  ZIP  TO  ISL; 
DONT  ZIP; 

ZIP  THROUGH  <PROGRAM  NAME>; 
re 

<PROGRAM  NAME>  ::=  TWST/BNF2FPL/FPL2PAR/PAR2ALG/ISL/ALG0L. 
use  of  these  control  statements  is  self-evident. 
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3-2. 5  Program  Parameter  Control 

Each  of  the  programs  in  the  TWS  has  certain  program  parameters 
which  are  normally  assigned  default  values  that  permit  compiler  generation 
for  many  small  languages.   It  is  possible,  however,  that  a  particular  language 
may  require  more  execution  time,  a  larger  stacksize,  or  a  higher  B-5500  core 
memory  estimate  to  run  successfully  through  some  phase  of  the  TWS.   Corres- 
pondingly, it  may  be  desirable  when  processing  some  smaller  languages  to 
decrease  the  values  of  some  of  these  program  parameters.   This  can  be  done  with 
the  three  program  parameter  control  statements  shown  below: 

<PROGRAM  NAME>  PRIORITY  =  <*N>; 

<PROGRAM  NAME>  CORE  -  <*N>; 

<PROGRAM  NAME>  STACK  =  <*N>; 

where  <PROGRAM  NAME>  was  defined  in  the  last  section  and  <*N>  is  a  positive 
integer.   These  set  the  priority  (and,  implicitly,  the  time  limit),  the  core 
estimate,  and  the  stacksize,  respectively,  of  the  program  designated.   These 
parameters  are  then  used  in  zipping  to  the  program.   If  the  <PROGRAM  NAME> 
is  COMPILER,  the  parameters  are  passed  to  the  ALGOL  compiler  and  become 
the  default  parameters  for  the  generated  language  compiler. 

3> 2 .6  Executable  Compiler  Options 

It  was  noted  in  section  3-1  that  a  Floyd  production  parser  generated 
by  the  TWS  may  be,  to  a  greater  or  a  lesser  extent,  an  executable  parser. 
The  default  option  is  a  parser  which  is  wholly  interpretive,  but  an  executable 
version  of  any  of  the  three  parser  sections  may  be  requested  by  use  of  the 
control  statements  shown  below: 

EXECUTABLE  LOOKAHEAD; 

EXECUTABLE  FILL  TABLES; 

EXECUTABLE  FLOYD  PRODUCTIONS;  . 
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If  the  lookahead  and  fill  tables  portions  of  the  parser  are  interpretive, 
the  resultant  compiler,  L/DISK,  may  only  he  executed  if  L/TABLESF  is  resident 
on  disk.  By  making  these  two  portions  executable,  the  parser  becomes 
a  self-contained  unit  and  compilation  in  L  requires  only  L/DISK. 

3'2.7  Miscellaneous  Control  Options 

CLOSE,  CLOSE  LP,  CLOSE  LINEPRINTER,  or  CLOSE  LINE  PRINTER:   applies 
to  BNF2FPL;  it  causes  a  separate  file  of  output  to  be  created  each  time  an 
error  occurs  during  execution  of  BNF2FPL.   In  this  way  a  user  can  ascertain 
the  cause  of  some  errors  before  BNF2FPL  runs  to  completion. 

LONG  LOOKAHEAD:   applies  to  BNF2FPL;  it  specifies  a  four  symbol 
lookahead  to  be  used  in  differentiating  before  deciding  that  the  group  cannot 
be  built.   If  the  Floyd  productions  of  a  group  being  generated  cannot  be 
differentiated  by  a  three  symbol  lookahead  and  if  combination  is  not  possible, 
the  group  is  not  normally  built  and  the  BNF2FPL  translation  fails.   In 
practice  it  has  been  found  that  when  a  lookahead  of  three  symbols  fails,  no 
additional  amount  of  lookahead  will  help. 

COMBINE  FIRST:   applies  to  BNF2FPL;  it  specifies  that  Floyd  produc- 
tion combination  be  attempted  after  a.  one  symbol  lookahead  has  failed  to 
differentiate,  but  before  attempting  a  two  or  three  symbol  lookahead;  if  combina- 

is  not  possible,  two  and  three  symbol  lookaheads  will  be  attempted 
before  abandoning  the  group. 

FLOYD  PRODUCTIONS  PER  PROCEDURE:   <*N>:   applies  to  PAR2ALG-   When 
creating  an  executable  parser,  PAR2ALG  generates  procedures  --  each  containing 
some  specified  number  of  the  Floyd  productions  of  the  language.   This  number 
ically  100,  but  may  be  set  by  the  language  designer  to  any  desired 
• 
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GROUPS  PER  PROCEDURE:   <*N>:   applies  to  PAR2ALG;  determines  the 
number  of  groups  of  Floyd  productions  in  each  executable  parser  procedure. 

PROGRAM  SYMBOL:   <X>:   is  followed  by  a  nonterminal  name,  say  <X>, 
■which  is  taken  to  be  the  unique  objective  symbol  of  the  language  in  question; 
if  this  option  is  not  used,  the  first  nonterminal  to  appear  in  the  syntax 
specification  is  taken  as  the  unique  objective  symbol  for  the  language. 

SPECIAL  SYMBOLS:   <SPECIAL  WORD  LIST>:   may  be  used  to  force  a 
particular  ordering  of  the  special  words  of  the  language  which  are  otherwise 
numbered  in  the  order  in  which  they  first  appear  in  the  syntax. 

3-3  Burroughs  B-5500  Control  Cards  for  Executing  TWINKLE 

The  TWINKLE  translator  is  executed  like  a  compiler  on  the  B-5500 
system.  When  the  syntax  to  be  translated  is  on  cards,  the  following  deck 
set  up  may  be  used: 

?  USER  -  Language  designer's  user  code 
?  COMPILE  A/B  WITH  TWINKLE  LIBRARY 
?  DATA  CARD 

input  syntax 
?  END. 
Since  TWINKLE  does  not  create  executable  code,  the  file,  A/B,  is  not  used, 
and  the  name  may  be  specified  arbitrarily  by  the  language  designer.   Because 
this  file  is  not  used,  either  of  the  following  forms  may  be  used  when  the 
input  syntax  is  a  file  on  disk,  say  PLl/SYNTAX: 

?  USER  =  Language  designer's  user  code 
?  COMPILE  A/B  WITH  TWINKLE  LIBRARY 
?  TWINKLE  FILE  CARD  =  PLl/SYNTAX  SERIAL 
?  END: 


or 
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?  USER  =  Language  designer's  user  code 
?  COMPILE  PL1/ SYNTAX  WITH  TWINKLE  LIBRARY 
?  END. 

In  the  latter  case,  TWINKLE  discovers  that  the  input  is  not  on  cards  and  that 
no  file  has  been  equated  to  file,  CARD.   It  then  investigates  the  code  file  and, 
if  it  exists  on  disk,  takes  it  as  the  file,  CARD.   In  the  former  case  a  file 
has  been  equated  to  f ile,  CARD,  so  this  is  taken  as  the  input  syntax.   In  this 
case, the  code  file,  A/B,  is  not  used  and  may  be  named  arbitrarily. 
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k.       IMPLEMENTATION  OF  THE  TWINKLE  TPANSLATOR 

The  TWINKLE  translator  has  been  implemented  with  the  TWS  in  a 
bootstrapping  fashion.  The  preliminary  version  of  the  translator  was  written 
in  BNF  and  processed  on  the  portion  of  the  TWS  then  existing,  which  was 
essentially  equivalent  to  the  BNF2FPL,  FPL2PAR  and  PAR2ALG  stages  of  the 
current  TWS.  Each  subsequent  revision  to  the  TWINKLE  translator  was  imple- 
mented with  the  aid  of  its  predecessor.  Thus,  although  the  present  syntax 
is  much  more  sophisticated  than  the  initial  syntax, it  is  also  shorter  and 
considerably  more  readable.   The  following  sections  detail  some  of  the 
salient  features  of  the  TWINKLE  translator. 

k.l     NONTAB,  SYMTAB  and  OPRTAB 

As  each  nonterminal  is  read  from  the  input  syntax,  its  name  is  com- 
pared against  all  those  presently  entered  in  NONTAB.   If  a  match  is  found, 
the  corresponding  nonterminal  number  is  extracted  from  the  relevant 
field  of  the  header  word  for  the  matching  table  entry.   If  no  match  is  dis- 
covered, a  new  entry  is  made.   The  entries  are  linked  through  the  header 
words  in  a  binary  tree  which  is  alphabe* J cally  ordered  by  the  nonterminal 
names.   The  format  of  the  entries  is  shown  below  in  figure  3*  Associated 
with  each  new  entry  into  NONTAB  is  an  entry  into  NTINDX  pointing  to  the  header 
word  of  the  nonterminal  in  NONTAB  which  facilitates  printing  out  the  non- 
terminal names  when  necessary.  Also,  if  the  CROSS  REFERENCE  print  option  has 
been  activated  by  the  user,  the  NTINDX  word  for  a  given  nonterminal  contains 
a  pointer  to  the  base  of  an  inter-linked  list  of  the  occurrences  of  that 
nonterminal  in  the  input  syntax  by  line  number.  The  actual  repository 
for  this  list,  as  well  as  those  for  the  other  nonterminals,  terminals,  and 
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action  symbols  from  the  input  syntax,  is  an  array  called  OVERALLINDEX,  each 
of  whose  entries  contains  a  line  number,  a  bit  showing  whether  the  specified 
occurrence  was  on  the  right  or  left  hand  side  of  a  production,  and  a  pointer 
to  the  entry  for  the  next  occurrence  of  the  item  in  whose  list  the  entry 
resides. 
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Figure  3-  An  entry  in  the  NONTAB  table 


Figure  3  shows  the  details  of  a  single  entry  in  NONTAB.   Consider, 
first,  the  header  word.  Nonterminals  (with  the  exception  of  the  unique 
objective  symbol)  used  in  the  syntactic  input  must  appear  on  the  left  hand 
side  of  at  least  one  production  and  on  the  right  hand  side  of  at  least  one 
(not  necessarily  different)  production.  The  INLHS  bit  is  set  on  recognizing 
the  nonterminal  as  the  left  hand  side  of  a  production  and  the  INRHS  bit  is 
set  on  recognizing  it  in  the  right  hand  side  of  a  production.  These  bits  are 
checked  at  the  conclusion  of  syntax  input  and  any  discrepancies  are  reported 
as  errors  on  the  TWINKLE  output  file, LINE.  The  SYMBOLVALUE  field  contains 
rial  number  (code)  of  the  nonterminal  symbol  represented  by  this 
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NONTAB  entry.   Given  a  nonterminal  name  of  k  characters,  n  of  the  WORDS 
field  and  m  of  the  CHARS  field  are  given  by  n  =  [k/l6]  and  m  =  k  -  6*  (n+l). 
These  two  fields,  taken  together^  determine  the  extent  of  useful  information  in 
the  remaining  words  of  the  NONTAB  entry.   Finally,  the  LEFTPOINTER  and  RIGHT- 
POINTER  fields  contain  pointers  to  subsequent  entries  in  the  alphabetic  binary 
tree  which  NONTAB  comprises.   The  remaining  words  in  the  NONTAB  entry  consist 
of  n  words  containing  6  characters  each  of  the  nonterminal  name  right  justified 
with  2  unused  characters  at  the  left,  and,  in  the  last  word,  2  unused  charac- 
ters, m  characters  from  the  nonterminal  name,  and  blanks  filled  to  the  right. 

Corresponding  to  NONTAB  and  NTINDX  for  nonterminal  storage 
are  the  pairs  of  tables  (SYMTAB,  STINDX),  and  (OPRTAB,  OTINDX)  for  storing 
special  symbols,  and  semantic  symbols,  respectively.   As  mentioned  above,  the 
line  by  line  index  information  for  both  these  types  of  symbols  is  stored  in 
OPERALLINDEX  along  with  that  for  nonterminals.   While  STINDX  and  OTINDX  are 
identical  counterparts  to  NTINDX,  entries  in  SYMTAB  and  OPRTAB  differ  slightly 
from  those  in  NONTAB  and,  in  fact,  from  one  another.   In  the  case  of  SYMTAB, 
there  is,  clearly, no  need  for  the  INLHS  and  INRHS  bits  since  a  special  symbol, 
if  it  appears  at  all,  must  appear  on  the  right-hand  side  of  a  production. 
Consequently,  in  the  header  words  for  SYMTAB,  these  bits  are  included  as  a 
portion  of  the  SYMBOLVALUE  field.   In  OPRTAB  header  words  it  is  also  clear 
that  the  INLHS  and  INRHS  bits  are  unnecessary,  but  here  the  first  bit  is  unused 
and  the  second  bit  becomes  the  USED  bit  denoting  an  action  or  test  symbol 

that  has  been  declared  in  the  syntax.   This  bit  is  read  by  ISL/DISK  to  deter- 
mine which  actions  it  must  get  from  the  file,<LANGUAGE  NAME>/ACTIONS .   It  is 
also  used  by  TWINKLE  to  catch  duplicate  declarations  of  the  same  semantic  name. 

k.2      PROTAB,  PRODS  and  PDLIST 

The  primary  table  into  which  TWINKLE  collects  the  BNF  productions  which 
it  produces  from  its  TWINKLE  input  is  PROTAB.  Figure  k   shows  the  fields  of  a 
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PROTAB  word.  The  FLAGS  field  comprises  a  set  of  six  one  bit  flags  carrying 
0       6      12     18  30      36 


FLAGS 

NEXT 

LHS 

TYPE 

ENTRY 

SYMBOL 


Figure  h.      PROTAB  word  format 


various  pieces  of  information.  These  flags  are  referred  to  as:  IREC,  NOBACK, 
TRMDER,  LASTNT,  SFLAG  and  REC  The  IREC  flag  is  set  only  in  the  first  word 
of  a  production  and  denotes  an  indirectly  left  recursive  production.  That  is, 
a  production  of  the  form: 

<A>  : :  =  <B>  a 
for  which  <A>  is  a  headsymbol  of  <B>. 

When  the  NOBACK  flag  is  set,  the  symbol  in  the  SYMBOL  field  is  not 
to  be  back-substituted  into  this  PROTAB  location.  If  the  symbol  in  the  SYMBOL 
field  has  a  terminal  derivation,  then  the  TRMDER  flag  is  set.  The  LASTNT 
flag  is  set  when  the  symbol  in  the  SYMBOL  field  is  a  nonterminal  and,  except 
for  possible  trailing  semantic  symbols,  is  the  last  symbol  in  the  production. 
The  SFLAG  flag  heralds  a  semantic  symbol  as  the  next  symbol  in  the  production. 
Finally,  the  REC  flag  is  set  in  the  first  symbol  of  a  production  if  the  symbols 
in  the  LHS  and  SYMBOL  fields  are  the  same  (i.e.,  if  the  production  is  left 
recursive).   The  remaining  fields  are:   the  NEXT  field  which  gives  the  number 
of  words  to  the  beginning  of  the  next  production,  the  LHS  field  which  contains 
the  number  of  the  nonterminal  being  defined,  and  the  TYPE  and  ENTRY  fields  of 
this  particular  right-hand  side  symbol. 

TWINKLE  performs  a  number  of  grammar  transformations  on  a  local  level. 
Frequently  more  than  one  production  is  being  built  simultaneously,  as  happens 
when  nested  definitions  are  being  translated,  or  when  lists  are  being  imple- 
ments. These  difficulties  make  it  very  cumbersome  for  TWINKLE  to  put  produc- 
tions directly  into  PROTAB.   To  circumvent  these  problems  TWINKLE  uses  a 
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556  element  entry  table  (PRODS )  as  a  directory  and  status  table  for  255  thirty- 
two-  symbol  productions  which  are  stored  in  the  PDLIST  array.  The  words  of 
PRODS  form  a  list  linked  forward  through  the  NEXTPD  fields  and  backwards 
through  the  IASTPD  fields.   The  first  entry  of  PRODS  acts  as  a  base  for  the 
productions  currently  in  use.   The  base  of  available  productions  is  given  by 
the  integer  variable,  FIRSTPDA VAIL.   To  manipulate  these  two  structures,  TWINKLE 
uses  two  procedures:   GETPROD  and  GIVEUP.   GETPROD  is  an  integer -typed  pro- 
cedure which  has  no  arguments  and,  when  called,  returns  the  address  of  the  next 
available  element  of  PRODS  after  incorporating  it  into  the  link  structure  and 
making  the  necessary  modifications  to  the  various  list  pointers.   GIVEUP  has 
as  its  sole  argument  the  address  of  an  element  of  PRODS  to  be  removed  from 
the  link  structure  and  returned  to  available  pool.  The  PDLIST  symbols  cor- 
responding to  PRODS(N)  are  PDLIST  (32  x  N)  through  PDLIST  (32  X  N  +  31). 

In  addition  to  serving  as  the  link  structure  for  the  productions  in 
PDLIST,  each  entry  of  PRODS  contains  the  following  information  about  the 
production  with  which  it  is  associated: 

(i)   COMPLETE:   a  flag  which  indicates  that  the  associated  production  is  no 
longer  being  extended; 
(ii)   LEVEL:   an  eight  bit  field  recording  the  level  of  bracket  nesting  at 
which  the  production  originated; 
(iii)   LAMDA:   a  flag  which  indicates  whether  the  production  has  participated 
in  empty  context  absorption; 
(iv)  NEXT SYMBOL:   a  five  bit  field  containing  a  count  of  the  symbols  currently 
in  the  production; 
(v)   DORNO:   a  three  bit  field  which  identifies  whether  the  left-hand  side 
of  the  production  is  a  simple  nonterminal  or  one  of  the  several 
TWINKLE  generated  nonterminal  types; 
(vi)  LHS:  a  twelve  bit  field  containing  the  nonterminal  number  of  the 
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left-hand  side  of  the  production. 

Each  word  of  PDLIST  contains  only  the  left-hand  side  of  the  produc- 
tion in  the  fields,  IjHSDORNO  and  LHS,  and  one  symbol  from  the  right-hand  side  in 
the  fields:  DORNO,  TZPE,  and  ENTRY.   The  remaining  information  necessary  in 
PROTAB  is  not  filled  in  until  a  production  actually  enters  PROTAB. 

Productions  which  are  being  created  in  PDLIST  may  be  extended  by 
calling  the  procedure, ADDON.  ADDON  has  two  arguments:   the  first  is  the  number 
of  the  production  to  be  extended;  the  second  is  the  symbol  by  which  it  is  to 
be  extended.   If  the  symbol  to  be  added  is  a  TWINKLE -generated  nonterminal 
representing  the  alternatives  of  a  nested  definition  set,  the  procedure 
for  adding  it  to  a  production  is  somewhat  complex.  Each  of  the  alternatives 
must  be  added  on  individually  and,  if  more  than  one  alternative  is  present, 
new  productions  must  be  created.  Thus,  for  example,  if  Oi   represents  the 
string  of  symbols  in  the  production  being  extended,  and  f3  through  p  represent 
the  strings  of  symbols  in  the  alternatives  of  the  symbol  being  added  on, 
ADDON  will  replace  the  production: 

<n>  : : -  a 


by  n  productions: 


<n>  : :=  a& 
<n>  :  :  =  apg 

<n>  : : =  OB 

Kn 


At  the  same  time  ADDON  removes  the  n  productions: 

<D>  .:=   px 

<D>  : : =  P2 


<D>  : :  =  B 

Kn 

where  -      the  TWINKLE -gene rated  nonterminal  referred  to  above.   By  expanding 
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nested  definitions  in  this  way,  TWINKLE  ensures  that  each  of  the  productions 
which  it  creates  retains  all  of  the  context  that  the  language  designer 
specified  in  the  original  TWINKLE  production. 

If  the  symbol  being  added  on  is  any  other  type  of  symbol,  say  the 
symbol,  a,  ADDON  replaces  the  production: 

<n>  : : =  a 
by  the  production: 

<n>  : : =  aa 
where  GC   is  as  above. 

When  it  has  been  arcertained  that  production,  P,  is  completed  and  is 
ready  to  be  put  into  PROTAB,  the  procedure,  PUTINPROTAB,  is  called  with  the  para- 
meter, P.   PUTINPROTAB  fills  in  the  NEXT  and  FLAGS  fields  of  the  production 
and  writes  it  directly  into  the  next  available  locations  in  PROTAB.   Once  this 
has  been  accomplished  the  production  is  returned  to  the  free  pool. 

k.3     PRODSTACK  and  LPSTACK 

The  TWINKLE  language  offers  the  user  only  two  recursive  constructs. 
These  are  nested  definitions  and  list  structures,  which  are  implemented  with 
PRODSTACK  and  LPSTACK,  respectively.  These  are  dimensioned  to  allow  nesting 
of  either  definitions  or  lists  to  a  depth  of  thirty,  but  this  may,  of  course, 
be  easily  altered  in  the  unlikely  event  that  it  needs  to  be.  The  formats  of 
words  in  these  two  stacks  are  shown  below   (in  figures  5  and  6,  respectively). 


SYMBOL 


EXSYMBOL 


Fieure  5.   The  format  of  a  PRODSTACK  entrv. 
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SEPD0RN0 

SEP 

LSITTYPE 
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LBDORNO 
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SEPTYPE 


SEPENTRY 


30 
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LBTYPE 


LBENTRY 


SEPSYMBOL 


LBSYMBOL 


EXSEPSYMBOL 


EXLBSYMBOL 


Figure  6.   The  format  of  a  LPSTACK  entry. 


PRODSTACK  is  simply  a  stack  of  single  symbols- -the  top  symbol  being 
the  left-hand  side  of  the  set  of  productions  currently  being  built.  Whenever 
the  left-hand  side  of  a  TWINKLE  production  is  encountered,  the  left-hand  side 
nonterminal  symbol  is  pushed  into  PRODSTACK.   Similarly,  when  the  left  square 
bracket  of  a  square  brackets  construct  is  encountered,  a  TWINKLE- generated 
temporary  dummy  (the  DORNO  field  is  set  to  one)  is  created  and  pushed  into 
PRODSTACK.   Right  square  brackets  and  semicolons,  which  end  square  bracket 
constructs  and  productions,  respectively,  cause  the  top  of  PRODSTACK  to  be 
popped.   PRODSTACK  is  used  in  assigning  names  to  TWINKLE- gene rated  permanent 
dummy  nonterminals  in  the  following  manner.  When  such  a  dummy  is  required 
(e.g.,  in  the  generation  of  lists,  see  below),  PRODSTACK  is  searched  downward 
from  the  top  for  a  natural  nonterminal  (which  is  identified  by  a  zero  in  the 
DORNO  field) .  There  must  always  be  such  an  entry  because  PRODSTACK  always 
extends  to  the  beginning  of  some  TWINKLE  production  which  must  start  with  a 
natural  nonterminal.  The  alphanumeric  characters  which  make  up  the  name  of 
the  nonterminal  are  obtained  from  NONTAB.  The  desired  name  is  then  created 
to  these  characters  a  blank,  the  characters  "DUMMY"  another  blank, 
and  finally  a  number  unique  to  this  nonterminal.   Since  blanks  cannot  appear 
in  natural  nonterminal  names,  these  serve  to  ensure  that  no  duplication  of 
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nonterminal  names  can  arise  by  this  procedure.  As  an  example  of  this,  the  list 
structure  in  the  TWINKLE  production: 

A  <PROGRAM>  CONSISTS  OF  A  LIST  OF  <STATEMENT>S ; 

would  be  implemented  with  a  permanent  dummy  nonterminal  named  PROGRAM  DUMMY  1. 

Each  entry  of  LPSTACK  eventually  contains  all  the  information  neces- 
sary to  construct  the  BNF  equivalent  productions  for  the  list  structure  which 
generated  it.  Whenever  the  list  type  of  a  list  structure  is  encountered,  a 
new  word  is  pushed  into  LPSTACK  with  an  appropriate  setting  of  the  LISTTYPE 
bit  (i.e.,  1  for  a  nonempty  list  and  0  for  a  possibly  empty  list).  When  a 
list  base  is  recognized,  the  sub-fields  of  the  EXLBSYMBOL  field  are  set  in  the 
top  word  of  LPSTACK  to  identify  the  base.   Similarly,  recognition  of  a  list 
separator  causes  the  subfields  of  the  EXSEPSYMBOL  to  be  filled  in  the  top 
word  of  LPSTACK;  the  SEP  bit  is  set  to  zero  for  a  definite  separator 
and  to  one  for  a  possibly  empty  separator.   If  the  list  does  not  have  a 
separator,  the  EXSEPSYMBOL  field  is  set  to  indicate  an  empty  separator 
and  the  SEP  bit  is  set  to  zero. 

The  LPSTACK  entry  does  not  reflect  the  type  of  recursive  desired  for 
the  list,  i.e.,  left  recursive  or  right  recursive.  However,  this  is  determined 
syntactically  and  is  transmitted  to  the  semantics  via  the  choice  of  the  action 
called.   Given  that  EXSEPSYMBOL  contains  the  symbol,  S,  and  that  EXLBSYMBOL 
contains  the  symbol,  B,  figure  7  shows  the  productions  which  are  generated 
to  implement  the  list  for  various  choices  of  SEP  and  LISTTYPE  where  <RD>  is 
the  TWINKLE- generated  permanent  dummy  which  implements  the  list  structure 
and  <XD>  is  a  TWINKLE -gene rated  temporary  dummy.   Recall  that  a  SEP  bit  of 
one  designates  a  definite  separator  and  a  zero  bit  designates  a  possibly 
empty  separator;  whereas,  a  LISTTYPE  bit  of  one  indicates  a  nonempty  list  and  a 
zero  bit  indicates  a  possibly  empty  list. 
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Figure  7-   Left  recursive  and  right  recursive  lists. 


Note  that  possibly  empty  lists  are  characterized  by  the  <XD>  nonterminal; 
whereas,  nonempty  lists  are  characterized  directly  by  the  list  implementing 
nonterminal  <RD>. 
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k.k     Any  Patterns 

An  any  pattern  comprises  38^  bits  (eight  words  of  kQ -bits  each)  for 
which  there  exists  a  one-to-one  correspondence  between  the  lower  numbered  bits 
and  the  terminal  symbols  of  the  language.  Bits  zero  through  63  correspond  to 
the  Gh   characters  of  the  Burroughs  B5500  system;,  bits  66  through  85  correspond 
to  the  possible  special  terminal  classes;  bits  86  and  above  correspond 
to  the  special  words  of  the  language.  Bits  Gh   and  65  are  never  set  in  an  any 
pattern  because  they  correspond  to  a  terminating  character  and  an  illegal 
character,  respectively.  Any  patterns  are  stored  end-to-end  in  a  512 -word 
array,  ANYPAT.   Each  bit  that  is  set  in  an  any  pattern  indicates  that 
the  corresponding  terminal  is  represented  by  the  any  pattern. 

During  the  preliminary  translation, any  patterns  are  actually  created 
in  the  negative- -that  is,  the  bits  are  set  if  the  corresponding  terminal  is 
not  represented  by  the  particular  any  pattern.  This  condition  is  rectified 
when  the  syntax  input  has  been  completed.  Each  pattern  is  transmitted  to  the 
procedure,  CLEANUP, which  converts  it  to  the  required  form  which  may  involve 
recursive  calls  of  CLEANUP  if  the  any  base  for  the  pattern  was  a  nonterminal. 

k.5     Grammar  Transformations 

The  PROTAB  generated  by  a  TWINKLE  translation  is  not,  in  general,  in 
a  form  acceptable  to  BNF2FPL.  A  number  of  transformations  must  therefore  be 
performed  on  a  BNF  grammar  to  increase  the  probability  of  its  acceptance  to 
the  overall  TWS.   In  addition, a  few  transformations  are  applied  to  increase 
the  efficiency  of  the  resultant  compiler.  These  are  described  below  in 
the  order  in  which  they  are  performed. 

h.^.1     Back  Context  Absorption 

In  translating  from  TWINKLE  into  BNF,  it  is  important  that  TWINKLE 
retain  any  context  in  the  BNF  that  was  inherent  in  the  original  TWINKLE 
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production.  When  a  left  recursive  list  is  created,  it  is  necessary  for  the 
non-recursive  productions  of  the  list- implementing  nonterminal  to  absorb 
any  of  the  context  prior  to  it  that  may  have  arisen  from  constructs  within 
the  TWINKLE  production  that  initially  gave  rise  to  the  list.  As  may  perhaps 
be  anticipated,  problems  begin  to  crop  up  when  more  than  one  list  is  included 
in  a  single  TWINKLE  production- -as  in  the  case  of  nested  lists. 

Each  time  a  definition  is  complete  (i.e.,  whenever  a  slash,  right 
square  bracket,  semicolon,  or  special  word,  OR,  is  encountered),  the  following 
context- absorbing  algorithm  is  invoked.  Let  {Pn|n  =  !>•••■>  N}  be  the  set 
of  productions  in  PDLIST  and  {D  |n  =  1,...,  N}  be  the  corresponding  entries 
in  PRODS.  Further,  let  P  (j)  denote  the  j-th  symbol  on  the  right-hand  side 
of  the  n-th  production  and  let  R  denote  the  corresponding  left-hand  side. 
The  right-hand  sides  of  Pn  are  then  scanned  for  the  occurence  of  a  left- 
recursive  TWINKLE- generated  dummy  nonterminal,  say  P  (j)  (such  a  nonterminal 
is  characterized  by  a  3  in  the  DORNO  field  discussed  in  section  h.2).      If 
j   >  1,  or  if  the  LAMDA  bit  of  PRODS  is  set,  a  new  production,   P  (k  =  N  +  l), 

K. 

is  created  as  follows: 


Pk(i  -  j  +  1)  =  Pn(i)   i  =  3,   0  +  1,...,  <ln, 

where  I     is  the  number  of  symbols  in  P  .   The  LAMDA  bit  of  D  is  set  to  zero, 
n  n  k 

'The  following  steps  are  then  taken  for  each  production  P  ,  for  which 


k  <  N  and  R=  P  (j)  while  R  /  pR(l): 

(i)  the  LEVEL  field  of  D.  is  set  to  OLDMARKER; 
(ii)  k  is  incremented  and  a  new  production,  P^  is  constructed  according 
to: 

Pk(i)  =  Pn(i)       1=1,  2,...  j-1 

PR(j-l+i)  =  Pk(i)   i  =  1,  2,  ...,  Itf 
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(iii)  the  LAMM  bit  of  D  is  set  to  one; 

K. 

(iv)  B^  =  V 

Finally,  P  is  removed  and  scanning  continues,  skipping  over  productions,  P  , 

in  which  the  LEVEL  field  of  D  is  set  to  OLDMARKER,  until  all  productions, 

including  those  created  above,  are  exhausted. 

There  is  one  circumstance  under  which  P, above, does  not  participate 

in  context  absorption.  This  is  the  case  in  which  both  R  and  Pn  (l)  are 

n      kv  ' 

left-recursive  dummies  and  where  among  the  {P  },  R  is  a  head  symbol  of  R. 
In  this  case,  context  absorption  will  lead  to  an  infinite  loop,  absorbing 
alternately  a  R  and  a  R  • 

The  following  example  provides  an  illustration  of  context  absorption 
applied  to  the  TWINKLE  production: 

<A>   ::=  a  LIST  [LIST  b  SEP  c]  d  LIST  e 

where  a,  b,  c,  and  d  represent  terminal  symbols.  The  productions,  before 
context  absorption,  are: 

P  :  <A>  ::  =  \a<RDl>  d  <RD3> 

P  :  <RD1>  :  :  -  *»<RD2> 

P  :  <RD1>  :  :  =  <RD1>  <RD2> 

P,  :  <RD2>  : :  =  Kb 

P  :  <RD2>  :  :  =  <RD2>  c  b 

P^ :  <RD3>  : :  =  Xe 

P  :  <RD3>  : :  =  <RD3>  e 

where  \   denotes  productions, P.,  for  which  the  LAMDA  bit  of  D.  is  set  to  1. 

Then: 

P  :   <RD1>  :  :  =  X  <RD2>  * 

P^ :  <RD2>  : : =  X  b  * 
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Pc:  <KD2>  ::=  <RD2>  c  b 
5 

P^:  <RD3>   ::=  X  e 

P  :  <RD3>  : :  =  <KD3>  e 

Po  :  <A>  : :  =  <KD1>  c  <PJD3> 


P  :  <RD1>  : 
P1Q:  <EP1>  : 
P      :   <PD2>  : 


-  \   a<RD2> 

-  <RD2> 

=  <KD1>  b 


are  the  productions  remaining  after  P,  (l)  and  P~(2)  have  participated 
in  context  absorption.  Note  that  P^l)  does  not  participate  because  the 
asterisk  indicates  that  the  LEVEL  field  of  Dp  is  equal  to  OLDMA.KKER.   Since 
P  (l)  and  P7(l)  cannot  participate  because  they  lack  a  X  : 


10' 


11' 


12' 


13' 


<RD1>  : 

:  = 

\  <ED2>  * 

<ED2>  : 

:  = 

X  b  * 

<ED2>  : 

:  = 

<KD2>  c  b 

<RD3>  : 

:  = 

\e     * 

<RD3>  : 

:  = 

<RD3>  e 

<RD1>  : 

:  = 

<RD2> 

<RD2>  : 

:  = 

<RD1>  b 

<A>   : 

:  = 

<ED3> 

<ED3>  : 

:  = 

<RD1>  c  e 

<RD2>  : 

*  s; 

\   a  b 

show  the  productions  remaining  after  context  has  been  absorbed  from  Po(3)  and 
2).  Note  that  the  duplication  of  P   from  P  is  inhibited.  Finally: 


Pc.:   <RD2>  : 
5 

P  :  <KD3>  : 


:=  <RD2>  c  b 
:=  <RD3>  e 
\0:   <RD1>  ::=  <RD2> 
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P   :  <ED2> 

P12:  <A> 

P  :  <RD3> 

P . :  <RD2> 


=  <RD1>  b 
=  <RD3> 
=  <RD1>  c  e 
=  X   a  b 


show  the  results  of  eliminating  all  productions  marked  with  an  asterisk.  Note 
also  that  RD1  is  no  longer  explicitly  left-recursive  but  retains  implicit 
left-recursiveness  through  P   and  P  •   It  is  easy  to  see  that  the  terminal 
strings  defined  by  the  fast  set  of  productions  above  are  exactly  those 
defined  by  P  through  P  originally. 

Context  absorption  is  a  local  grammar  transformation  and  is,  there- 
fore, carried  out  in  PDLIST  before  the  productions  are  entered  into  PROTAB. 
All  of  the  grammar  transformations  are  global  and  are  performed  in  PROTAB,  it- 
self.  To  discuss  these  with  some  facility,  the  notation  of  this  section  will 
be  altered  and  augmented  as  follows.   The  i-th  production  in  PROTAB  will  be 
denoted  by  P.,  its  right-hand  side  symbols  by  T-(j),   where  j  ranges  from  1 
through  I. ,   the  number  of  symbols  on  the  right-hand  side.  The  left-hand  side 
will  be  denoted  by  R. •  Finally,  for  each  nonterminal  n,  N(n)  and 
T(n)  will  be  the  sets  of  nonterminal  and  terminal  head  symbols  of  n,  respec- 
tively. 

h . 5 . 2  Empty  Removal 

The  control  of  ADDON  and  PUTINPROTAB  is  such  that  empty  symbols  may 
appear  in  PROTAB  only  as  productions  in  themselves.  That  is,  if  a  production 
contains  an  empty  symbol,  that  must  be  its  only  symbol.   Even  in  this 
relatively  mild  form,  however,  empty  symbols  are  unacceptable  to  BNF2FPL  and 
it  falls  to  TWINKLE  to  remove  them  by  back-substituting  and  collapsing  PROTAB 
around  them.   Since  PROTAB  always  contains  the  initial  production: 

<WHOLE  PROGRAM>  : : =  J_  <PROGRAM  SYMBOL>  J_ 
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where  <PROGRAM  SYMBOL>  is  the  unique  objective  symbol  of  the  language,  and 
"_L"  is  a  special  termination  terminal  symbol  that  appears  nowhere  else  in 
PROTAB.  Furthermore,  there  is  no  nonterminal  for  which  the  only  production 
is  LAMBDA  since  there  is  a  check  that  each  nonterminal  has  a  terminal  string 
derivation. 

Each  production,  P.,  for  which  I.    =   1  is  tested  to  determine  whether 
P.(l)  is  the  empty  symbol  LAMBDA.  When  such  a  production  is  found,  PROTAB 

is  scanned  for  occurrences  of  R. .   Such  an  occurrence,  say  P  (j)  =  R. , 

1  n  0/    i 

generates  a  new  production,  P, at  the  end  of  PROTAB  according  to  the  rules: 

(i)  if  l     =   1  then 

'      n 

a)  4k  -  1 


b>  \-\ 


c)  Pv(l)  is  an  empty  symbol; 

(ii)  if  I    >  1  then 
n 

c)  Pk(m)  =  Pn(m)  m=l,  ...,j-l;  Pk(m)=Pn(m+l),  m-J,...,^. 

In  the  first  case,  P  will  be  picked  up  in  its  turn  as  an  empty  production. 
In  the  second  case,P,  will  eventually  be  scanned  for  occurrences  of  R.  and 
possibly  generate  further  new  productions.  During  the  course  of  this  pro- 
cedure new  productions  are  compared  against  existing  productions  in  PROTAB 
for  identity.  If  a  match  is  found  the  new  production  is  not  entered  into 
PROTAB. 

.  , . ';;  Back  Substitution  of  Singly  Defined  Nonterminals 

Unlike  LAMBDA  removal,  without  which  PROTAB  is  unacceptable  to 
BNF2FPL,  back- substitution  of  singly-defined  nonterminals  merely  serves  to 
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increase  the  overall  efficiency  of  the  resultant  compiler  by  decreasing  the 
number  of  reductions  required  to  recognize  certain  nonterminals. 

The  algorithm  for  back-substitution  is  very  straightforward  and 
proceeds  as  follows.  The  sei^  A,  of  singly  defined  nonterminals  is  determined 
by  one  pass  through  PROTAB.   Then,  for  each  nonterminal,  n,  in  A,  PROTAB  is 
scanned  for  productions,  P.,  in  which  P.(«j)  =  n  for  some  j  such  that  1  <  j  <  t.  • 
A  new  production,  P^  is  then  created  such  that: 

(i)  r^v 

(ID  ^  =  i±  +  tn,  .  1; 

(iii)  P. (m)  m  =  1, ...,  j  -  1; 

Pn , (m  -  J  +  1)  m  =  $t •  • » > J  +  tn . -  1; 
Pi(m  -  \,+  1)  m  =  J  +  l^t-o'tlj^ 

where  P  ,  is  the  single  production  for  which  R  ,  =  n.  The  production,?.,  is 
then  deleted  and  the  scan  for  occurrences  of  n  continues,  eventually  reaching 
P  and  checking  for  possible  further  occurrences  of  n. 

k.^.h     Dummy  Insertion 

It  has  been  mentioned,  briefly,  that  two  otherwise  indistinguishable, 
Floyd  productions  may  be  differentiated  by  a  look  ahead  of  at  most  three  symbols, 
If  this  much  look  ahead  is  insufficient,  BKF2FPL  attempts  to  combine  the  pro- 
ductions deciding  (in  essence)  that  the  differentiation  may  be  postponed.   Of 
course  differentiation  must  eventually  be  accomplished  by  look  ahead,  if  at  all. 
There  are  two  situations  in  which  this  combination  cannot  be  performed.  First, 
a  terminal  symbol  may  not  be  combined  with  a  nonterminal.   Second,  if  A  and  B 
are  two  nonterminals  for  which  a  combination  is  proposed,  that  combination 
cannot  be  carried  out  if  A  is  a  head  symbol  of  B  (or,  of  course,  if  B  is  a 
head  symbol  of  A).  The  reason  for  this  is  that  the  parser,  in  the  course  of 


6o 


looking  for  an  A  or  a  B,  will  then  be  satisfied  by  finding  an  A,  even  though 
that  A  may,  in  fact,  be  the  beginning  of  a  B  which  a  correct  parse  would 
discover. 

The  approach  to  this  problem  in  the  original  TWS  was  to  look  for  BNF 
productions  of  the  form: 


<N  >  : :  -  a  A  p 
<N  >   : :  =  a  <E>  y 


(1) 


where  a  is  a  nonempty  string  of  terminals  and/or  nonterminals,  and  A  is  a 
headsymbol  of  the  nonterminal,  B  (A  may  be  either  a  terminal  or  a  nonterminal) 
These  productions  were  modified  to; 


<N  > 
<N2> 
<Q> 


:=  a   <GP£ 
:=  a   <B>  7 
:=  A  . 


(2) 


Now  Q,  is  not  a  headsymbol  of  B  and,  if  a  Q  is  found,  there  can  be  no  question 
of  its  actually  heralding  a  B. 

This  can  create  problems,  however,  when  |3  =  P-iPo  an(^  there  exists  a 
production: 


<N  >  : :  ~  AP1t1   . 


(3) 


If  (3  is  more  than  three  symbols  long,  the  parser  is  unable  to  determine,  when 
it  finds  an  A,  whether  that  A  should  become  a  Q,  or  a  N  .   It  is  not  possible 
to  combine  since  the  Q,  production  calls  for  an  immediate  reduction. 

To  obviate  this  difficulty, the  present  system  performs  dummy  insertion 
as  a  dummy)  by  replacing  the  productions  (l)  by: 

a  <B> 


<N  > 


<N2> 


=  AP1P2 
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instead  of  the  productions  (2).  The  production  (3)  now  causes  no  problem  (if 
t\    and  p  are  differentiable)  because  the  burden  of  the  differentiation  can  be 
put  off  by  combination  of  the  strings  £2  and  T  .  Experience  has  shown  that 
this  modification  has  profound  effect  on  the  ease  of  writing  acceptable 
grammars. 

The  algorithm  by  which  TWINKLE  performs  dummy  insertion  is  based  on 
two  procedures,  MAKEDUMMYS  and  FIX,  which  call  one  another  recursively. 
MAKEDUMMYS  has  three  arguments   (BASIC,  FIRST,  and  LAST)  which  are  addresses  of 
productions  in  PROTAB.   Each  production  from  FIRST  to  LAST  is  compared  against 
the  production  at  BASIC  to  see  if  a  dummy  is  needed.   If  it  is  determined  that 
a  dummy  is  required  at  PROTAB  [I],  FIX  is  called  with  I  as  a  parameter  and  pro- 
ceeds to  make  the  necessary  alterations  to  PROTAB.   The  production  thus  created 
may,  in  turn,  require  dummies  when  compared  to  productions  prior  to  BASIC   To 
make  these  comparisons,  FIX  calls  MAKEDUMMYS  before  returning. 

k.6        TWINKLE  Output  Files 
U.6.1  TABLESF 

The  TABLESF  file  is  the  basic  thread  that  ties  the  TWS  together.   The 
first  record  of  TABLESF  contains  control  information  concerning  which  options 
are  in  effect,  a  directory  of  the  various  tables  appearing  in  later  records, 
and  a  brief  of  the  progress  through  the  system.  This  latter  contains  the 
last  program  to  run  successfully  and  the  dates  and  times  at  which  each  program 
was  most  recently  executed.   Below  is  a  list  of  entries  in  the  first  record 
of  TABLESF. 

LANGNAME  -  the  name  of  the  language  truncated  to  seven  characters; 

TABLEBEGIN  -  a  pointer  to  the  first  word  of  the  table  directory; 

PRINT OPT IONS  -  a  word  of  control  bits  for  printing,  and  a  few  other 
options; 

LASTPROGRAM  -the  number  of  the  last  program  to  run  successfully 


'> 


(0  =  TWINKLE;    1  -  BNF2FPL;    2  =  FPL2PAR;    3  =  PAR2ALG); 
ZIPTHROUGHBITS   -  the  number  of  the  program  through  which  the  user 

desires  the   system  to  zip  automatically; 
FIRSTGROUP  -  used  by  BNF2FPL; 
TWINKLEDATE 


TWINKLETIME 

BNFDATE 

BMFTIME 

FPLDATE 

FPLTBffi 

PARDATE 

PARTIME 

FPLPRIORITY 

FPLCORE 

PARPRIORITY 

PARCORE 

ISLPRIORITY 

ISLCORE 

ISLSTACK 

ALGOLPRIORITY 

ALGOLCORE 

ALGOLSTACK 

COMPPRIORITY 

COMPCORE 

COMPSTACK 
TABPRIORITY 
TABCORE 
TABSTACK 


N\ 


the  date  and  time  at  which  the 
indicated  program  was  last  run 
successfully; 


these  are  the  various  user  controlled 
execution  parameters  of  the  programs 
indicated;  the  prefix, COMP,  refers  to 
the  resultant  compiler  and  the  prefix, 
TAB,  refers  to  the  TWS  printing  program  , 
PRINTAB/TWS; 
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NOSYM 

NONDUM 
FDDERPROC 

STKTOP 

NTS 

TINDEXSTART 

NNS 
NTINDEXSTART   - 

NOS 

OPRINDEXSTART  - 

SPSTABPT 

SPSTABSTART 

NONTABPT 

NONTABSTART 

OPRTABPT 

OPRTABSTART 

PROTABPT 

PROTABSTART 

PATTERNLENGTH  - 

PATTERNPT 

PATTER1ISTART   - 


the  number  of  special  terminal  classes  required  by 

the  language; 

the  number  of  nonterminals  prior  to  dummy  insertion; 

the  number  of  Floyd  productions  per  procedure  as 

set  by  the  control  card  described  in  section  3.2.6; 

the  length  of  the  longest  production  in  PROTAB; 

the  number  of  special  words  used  in  the  language; 

the  record  in  which  the  special  word  index  table, 

STIKDX,  begins; 

the  number  of  nonterminals  used  in  the  language; 

the  record  in  which  the  nonterminal  index  table, 

NTINDX,  begins 

the  number  of  actions  and  tests  used  in  the 

language; 

the  record  in  which  the  action  index  table,  OTINDX, 

begins; 

the  number  of  entries  in  SYMTAB; 

the  record  in  which  SYMTAB  begins; 

the  number  of  entries  in  NONTAB; 

the  record  in  which  NONTAB  begins; 

the  number  of  entries  in  OPRTAB; 

the  record  in  which  OPRTAB  begins; 

the  number  of  entries  in  PROTAB; 

the  record  in  which  PROTAB  begins; 

the  length  of  each  any  pattern; 

the  number  of  entries  in  ANYPAT; 

the  record  in  which  ANYPAT  begins; 
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NOMORETABPT    -  a  dummy  pointer; 

NOMORETABSTART  -  the  first  available  record  at  the  end  of  ANYPAT. 

By  using  TABLEBEGIN  and  record  pointers  for  referencing  resident  tables,  the 
format  of  TABLESF  is  made  very  flexible.   In  fact,  several  additional  tables 
are  placed  in  TABLESF  as  a  language  runs  its  course  through  the  TWS.  The 
LASTPROGRAM  entry  ensures  that  no  program  in  the  TWS  will  operate  on  a  TABLESF 
file  that  has  not  been  properly  prepared. 

U.6.2  ACTIONS 

Although  semantic  information  is  also  included  in  the  TWINKLE  input, 
this  information  is  placed,  virtually  without  any  processing,  into  the  file, 
ACTIONS,  which  is  passed  on  to  the  ISL  translator  for  the  majority  of  its 
processing.  ACTIONS  is  a  file  of  card  images  of  which  the  first  contains 
the  number  of  different  actions  and  tests  used  in  the  syntax,  and  the  card 
number  on  which  the  semantic  tail,  if  any,  begins.   If  there  is  no  semantic 
tail,  this  latter  number  is  zero. 

Each  action  or  test  name  is  written  onto  the  next  available  card  in 
ACTIONS  when  it  is  read  for  the  first  time.  When  a  semantic  declaration  call 
is  encountered, the  code  which  defines  it  is  placed  on  consecutive  cards  in 
ACTIONS.  To  set  these  apart  from  the  action  and  test  names,  two  special  cards 
are  emitted  before  the  code  and  two  after  it.  The  first  card  emitted  has 
dollar  signs  in  the  first  four  columns  and  the  number  of  the  action  with 
which  the  test  is  associated  following  these.  The  second  card  has  only  the 
special  word, BEGIN.  The  first  card  following  the  code  has  only  the  special 
word,  END, and,  finally,  there  is  a  card  with  dollar  signs  in  the  first  four 
columns  once  again. 

Implicit  actions  are  treated  similarly  with  the  exception  that  a  name 
rated  for  these  and  placed  in  ACTIONS  along  with  the  code.  The 
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names  generated  for  these  actions  are  IMPLICIT!.,  IMPLICIT2,  etc. 

k.7     ZIP  Files 

TWINKLE  must  have  the  facilities  for  initiating  the  execution  of 
several  other  programs,  depending  on  the  various  control  parameters  obtained 
from  the  input.   Since  each  program  is  initiated  in  essentially  the  same  way, 
the  following  description  of  the  initiation  of  BNF2FPL  should  suffice  as  an 
illustration. 

When  it  has  been  determined  that  a  zip  to  BNF2FPL/TWS  is  required, 
the  translator  executes  a  SEARCH  on  file  BNF2FPL,  the  multifile-  and  file- 
identifiers  of  which  are  "BNF2FPL"  and  "TWS",  respectively.  This  determines 
whether  or  not  BNF2FPL/TWS  is  presently  in  the  disk  directory.   If  it  is  not, 
the  following  message  is  issued  to  the  system  SPO : 

#TWINKLE  SUSPENDED: 
BNF2FPL/TWS  NOT  IN  DIRECTORY 
OK  ZIP:   mAXOK 
NO  ZIP:   mAXNO 

where,  m  is  the  mix  number  of  the  TWINKLE  translator.  At  this  point,  the  opera- 
tor must  either  load  BNF2FPL/TWS  and  then  restore  TWINKLE 'to  execution  by 
entering  mAXOK  at  the  SPO,  or  terminate  the  TWINKLE  execution  by  entering  mAXNO 
at  the  SPO. 

Assuming  that  BNF2FPL  was  present  or  has  been  loaded,  TWINKLE  writes 
the  following  control  cards  in  BNFTEMPFILE : 

?  EXECUTE  BNF2FPL/TWS;  FLLE  NAME  -  Xaaaaaa 

?  STACK  =  nnnn 

?  DATA  Xaaaaaa 

ctctctclclclcl 

?   END 
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5-   SUMMARY 

The  TWINKLE  metalanguage  unifies  the  TWS  "by  accepting,  virtually 
without  alteration,  syntax  specifications  written  in  either  TBNF  or  BNF  and 
generating  either  TBNF  or  BNF  specifications  which  then  may  "be  used  to  create 
either  a  recursive  descent  or  a  deterministic  Floyd  production  parser,  respec- 
tively.  The  changes  necessary  to  he  made  to  the  input  involve  such  things  as 
additional  sharps  on  special  words  and  characters,  which  frequently  may  be 
accomplished  after  a  single  preliminary  run  through  the  translator. 

TWINKLE  goes  well  beyond  these  sub -languages,  however,  by  offering 
a  rich  syntax  for  creating  readable  English  descriptions  of  languages  which 
are  directly  acceptable  for  computer  manipulation.   Thus,  TWINKLE  achieves  the 
"lean  mix  of  compact  syntax  metalanguage  with  natural  language"  which  Perstein 
[2]  has  advocated.   The  sacrifice  for  this  generality  has  been  that  the  TWINKLE 
language,  itself,  is  much  more  difficult  to  describe  than  either  BNF  or  TBNF. 
Possible  ambiguities  arise  in  the  use  of  English  ;  the  interpretation  taken 
must  he  stated  explicitly.   It  is  felt,  however,  that  the  TWINKLE  interpreta- 
tion is  most  frequently  that  which  would  naturally  occur  to  native  speakers  of 
the  English  language  and  hence,  although  precise  definition  requires  much  more 
effort,  one's  familiarity  with  natural  English  makes  the  TWINKLE  syntax  of  a 
language  immediately  understandable. 

Floyd  [12]  offers  the  following  example  of  BNF  in  explaining  its 
metasymbolism : 

<for  statement>  : :=  <f or  clause>  <statement> 

<label>  :  <for  statement> 

which,  he  say  •  "can  be  read  'A  for-statement  is  defined  to  be  a  for-clause 
foil  -ftement  or  a  label  followed  by  a  colon  followed  by  a  for- 

:mer.  .    With  the  exception  that  TWINKLE  retains  the  angle  brackets  <and>, 
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this  latter  form  is  also  perfectly  valid  TWINKLE.   But  later  in  his  paper 
Floyd  remarks : 

"It  is  evident  that  a  complete  definition  of  a  programming 
language  may  be  expressed  far  more  concisely  by  a  PSG 
[Phrase  Structure  Grammar]  than  by  the  corresponding 
English  sentences  and  that  it  is  humanly  impossible 
to  write  those  sentences,  with  their  hundreds  of 
occurrences  of  'is  defined  to  be,'  'followed  by,'  and  'or'." 
While  the  conciseness  of  BNF  is  only  marginally  debatable,  it  is  clear,  from 
Appendix  B,  that  the  English  syntax  of  TWINKLE  was  neither  impossible  to  write 
nor  glutted  with  hundreds  of  these  phrases. 

Finally,  the  use  of  TWINKLE  cons  true ts,  such  as  lists  and  enclosures, 
allows  TWINKLE  to  create  a  BNF  syntax  which  has  a  significantly  higher  prob- 
ability of  acceptance  by  the  TWS  than  the  BNF  which  the  language  designer 
would  have  created  on  his  own.   This  is  accomplished  through  grammar  transfor- 
mations, such  as  back  context  absorption,  of  which  the  language  designer  may 
himself  be  capable,  yet  which  are  so  tedious  and  error  prone  that  he  is  loathe 
to  undertake  them. 
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APPENDIX  A 


RESERVED  WORDS  FOR  TWINKLE 


ACTALF 

OOLLAR 

NTALF 

SHARPS 

ACTIONS 

EITHER 

NTNUM 

SIGN 

ACTNUM 

EL 

NUMBER 

SIGNS 

AHEAD 

EMPTY 

NUMRERS 

SIZES 

ALGOL 

ENCLOSED 

NUMERICALLY 

SLASHES 

ALPHABETICALLY 

END 

OFF 

SLASH 

ALPHA 

EOUAL 

OF 

SPECIAL 

AMPERSAND 

EVERYTHING 

ONE 

SQUARE 

AMPERSANDS 

EXECUTABLE 

ON 

S 

AND 

EXPANDING 

OPEN 

STACK 

ANGLI- 

FILL 

OPERATOR 

STANDARD 

AN 

FIRST 

OPERATORS 

STAR 

ANY 

FLOYD 

OR 

STARS 

ARROW 

FOLLOWED 

PAR2ALG 

STARTING 

ARROWS 

FPL2PAR 

PARENTHESES 

STRING 

A 

GREATER 

PARENTHESIS 

STRINGS 

ASTERISK 

GROUPS 

PARSER 

SVMBOL 

ASTERISKS 

IDENTIFIER 

PATTERNS 

SYMBOLS 

BAC* 

IDENTIFIERS 

PERCENT 

SYNTAX 

BEGINNING 

INDFX 

PERIOD 

TABLES 

BEGIN 

INPUT 

PERIODS 

TABLESF 

BE 

IN 

PER 

TERMINAL 

BIT 

I 

POSSIBLY 

TFRMINALS 

BLANK 

ISL 

PRINTER 

THAN 

BNF2FPL 

IS 

PRINT 

TO 

BRACKET 

KLEENE 

PRIORITY 

TRMALF 

BRACKETS 

LAMBDA 

PROCEDURE 

TRMCHR 

BUT 

LANGUAGE 

PRODUCTION 

trmnum 

BY 

LEFT 

PRODUCTIONS 

T 

CHARACTER 

LESS 

PROGRAM 

TWST 

CHARACTERS 

LETTER 

PROTAB 

VIRGULE 

CLOSE 

LETTFRS 

0 

VIRGULES 

CODE 

LINEPRINTER 

QUESTION 

WHICH 

COLON 

LINE 

QUOTE 

WITH 

COLONS 

LIST 

QUOTES 

XREF 

COMBINED 

LONG 

RECURSIVE 

COMMA 

LOOKAHEAD 

REDUCED 

COMMAS 

LP 

REFERENCE 

COMMENT 

L 

RELATIONAL 

COMPILER 

MARK 

RESET 

CONSISTS 

MARKS 

RIGHT 

CORE 

NOBACK 

R 

CROSS 

NONCHARACTER 

SEMICOLON 

C 

NONCHARACTERS 

SEMICOLONS 

DEBUGGING 

NONEMPTY 

SEPARATED 

D  E  P  U  G  N 

NON 

SEPARATOR 

DETINED 

NONTERMINALS 

SEP 

DLSrEKT 

NOTHING 

SEQUENCE 

D  I  r,  I  T 

NOT 

SET 

DIGITS 

N 

SHARP 
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APPENDIX  B 

A  <TWINKlE  PROGPAM>  CONSISTS  OF  A  <LANGUAGE  SYNTACTIC  DESC*lPTION> 

FOLLOWED  BY  POSSIBLY  ONF  [SEMICOLON  OR  #ENDJ  FOLLOWED  BY  POSSIBLY 

ONE  <SEMAMTIC  TAIL>J 
*  <LANGUAGE  SYNTACTIC  DESCRIPTION*  CONSISTS  OF  A  LIST  OF  <CONTROL 

STAT*-MENT>S  SEPARATED  BY  SEMICOLONS  STARTING  WITH  A  <lAnGUAGE 

NAME  DESIGNATION*  FOLLOWED  BY  A  SEMICOLON  FOLLOWED  BY  A  LIST  OF 

<PRODUCTION>S  SEPARATED  BY  SEMICOLONS) 
A  <PR0DUCTI0N>  IS  DEFINED  TO  PE  AN  [<ARTICLF>  WHICH  IS  EITHER  [AN 

*A  OR  AN  fAN  OR  EMPTYJ]  FOLLOWED  BY  A  <NONTERMlNAL>  FOLLOWED  BY 
AS  <ARROw>  FOLLOWED  By  A  NONEMPTY  LIST  OF  <OEF In  I T ION>S  SEPARATED 

BY  EITHER  [A  SLASH  OR  AN  fOR)J 
AK  <ARRP*>  IS  EITHER  [COLON  COLON  EOUAL  SIGN   OR  *IS  OR  IIS  *DEplNED 

ITO  *BE  OR  ^CONSISTS  fOF]| 
A  <DErlNlTIPN>  CONSISTS  OF  A  LIST  OF  <SYMBOL>S  POSSIBLY  SFPARATFD 

BY  [#FOLLOWED  iBY  <ARTICLE>]  BEGINNING  WITH  AN  [<ARTlcLr>  FOLLOWEO 
BY  A  <SYMBOL>]J 
A  <SYMBOL>  IS  EITHER  [A  <SYNTACTlC  SYMBOL>  OR  A  SEMANTIC  SYMBOL> 
OR  A  <NULL  SYMBOL>  OR  AN  <EMPTY  SYMBOL>JI 

A  <SYNTACTIC  SYMBOL>  CONSISTS  OF  EITHER  [A  <SIMPLE  SYNTACTIC  SYMBOL> 
FOLLOWED  BY  AN  [AMPERSAND  OR  A  OUESTION  MARK]     OP  POSSIBLY  ONE 

[•POSSIBLY  «ONE]  FOLLOWED  By  A  <GENERAL  SYNTACTIC  SYMBOl>U 
A  <GENtRAL  SYNTACTIC  SYMBPL>  CONSISTS  OF  EITHER  [A  <SFEDEp  LIST>  OR 

A  <SIMPLE  SYNTACTIC  SymBOL>]  FOLLOWED  BY  A  POSSIBLY  EMPTY  LIST  OF 
<ENfLOSURE  OPERATOR>S) 

A  <SIMPLF  SYNTACTIC  SYMBOL>  IS  A  <TERMINAL>  OR  AN  <ANY  SYMBOL>  OR 
A  <NONTErmINAl>  OR  POSSIBLY  ONE  #EITHER  FOLLOWED  BY  EIThER 
[A  <SOUARr  BRACKET  CONSTRUCT>  OR  A  <NESTED  PRODuCTION>3  FOLLOwED 
BY  POSSIBLY  ONE  <KLEENE  STAR>J 

A  <SO|iARE  BRACKET  CPNSTruCT>  IS  A  LIST  OF  <DEF  I  Nl  TlON>S  SEPARATED 
BY  EITHER  [A  SLASH  OR  #OR]  ENCLOSED  IN  SQUARE  BRACKETS* 

A  <NESTED  PRODUCTlON>  IS  [AN  <ARTICLE>  FOLLOWED  BY  A  <NpNT&RMlNAL> 


*     100 

*     200 

*     300 

*     400 

*     500 

*     60C 

*     700 

*     800 

*     900 

*    1000 

*    1100 

*    1200 

*    1300 

•    1400 

*    1500 

*    1600 

*    1700 

*    1800 

*    1900 

*    2000 

*    2100 

*    2200 

*    2300 

*    2400 

*    2500 

*    2600 

*    2700 

*    2600 

*    2900 

*    3000 

*    3100 

TO 


FOLLOWED  BY  POSSIBLY  ONE  fWHlCH  FOLLOWED  BY  AN  <ARROW>  FOLLOWED 
BY  a  LIST  OF  <0EFINITI0N>S  SEPARATED  BY  EITHER  [SLASH  OR  #ORJ] 

ENCLOSED  IN  SOUARE  BRACKETS! 
A  <KLEENf  STAR>  CONSISTS  OF  POSSIBLY  ONE  [fCLOSE  OR  fOPEN]  FOLLOWED 
BY  EITHER  [A  STAR  OR  #♦]) 

AM  <ENCLOSURE  OPERATOR>  CONSISTS  OF  fENCLOSED  #IN  FOLLOWED  BY  EITHER 
[#PARENThESES  OR  fSOUARF  iBRACKETS  OR  IAN6LE  «BRAC*FTS  OR  A 
<SIMPLE  SYNTACTIC  SYMBOL>  FOLLOWED  BY  POSSIBLY  ONE  *S  FOLLOWED  BY 
POSSIBIY  ONE  [#AND  <SIMPLE  SYNTACTIC  SYHBOL>  FOLLOWED  By  POSSIBLY 
ONE  #S]]J 

A  <SEFDED  LIST>  IS  FITHER  [A  <LEFT  RECURSIVE  L IST>  OP  A  <plGHT 
RECURSIVE  LIST>)  FOLLOWED  BY  POSSIBLY  ONE  [<LIST  SFED>  WHICH  IS 
DEFINED  TO  RE  EITHER  [ISTARTING  OR  #BEGlNNlNG]  #WITH  <ApTICLE> 
FCLI  UwED  BY  EITHER  [A  <SIMPlE  SYNTACTIC  SYMBOL>  OR  A  <SEEDED 
LIST>ni 

AN  <ANY  SYHBDL>  CONSISTS  OF  AN  <ANy  BASE>  FOLLOWED  BY 

POSSIBLY  ONE  <EXCEPTlON>J 
AN  <ANY  PASE>  IS  DEFINED  TO  BE  *ANY  FOLLOWED  BY  tA  <NONTEpMlNAL> 


OR  #DIGIT 

PR  1LETTER 

PR  tSPECUl  tCHARACTER 

OR  tCHARACTER 


OR  fDIfilTS 

OR  BETTERS 

OR  fSPFCIAl  ^CHARACTERS 

OR  iCHARACTERS 


OR   iPELATlPNAL  IpPfRATOR* 
OR   #NOM  tCHARACTERS 


OR   #NPNCHARACTER< 
OR   ITERMINALS 


II 


OR   ^RELATIONAL  #PPERATPR 
PR   *NON  ^CHARACTER 

PR   INONCHAPACTER 

PR   ITEPHINAL 
AM  <FxCEPTIpM>  CONSISTS  oF  #BUT  FOLLOWED  BY  EITHER  tA  LtSt  OF 

<TFRMINAL>S  SFPARATED  BY  *Bl)T   OR  A  LIST  OF  <TERHINAL>S  POSSIBLY 
SEPARATED  BY  EITHER  [SLASHES  OR  #OR  ]   FNCLOSED   IN   SOUARE 
BRACKFTS] J 
*  <TEPMINAL>  IS  DEFINED  TO  BE  EITHER  [A  <SYHBpLIC  TERMInAl>  OP  AN 


3200 
3300 

3100 
3500 
3600 

3700 
3800 

3900 

4000 

4100 

4200 

4300 

4400 

4500 

4600 

4700 

4800 
4900 

5000 
5100 

5200 
5300 

5400 
5500 

5600 

5700 
5800 

5900 

6000 

6100 

6200 
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<english  terminals! 
a  <symbolic  termlnal>  is  either  [1blank  or  *  <terminal  class  name> 

enclosed  in  <left  brackft>  and  <right  brackft>  or  *code  followed 
by  a  numrfr  or  a  sharp  followed  by  any  terhlnal  but  number  or 
a  <cHaracter>  or  an  identifier  or  a  number  or  ialpha  followed  by 

an  <alpha  character  string>  or  ialpha  followed  by  a  list  of  <alpha 
character  string>s  possibly  sfparatfd  ry  commas  enclosfd  in 

scuare  brackets]) 

AN  <AlPHA  CHARACTER  STRINO  CONSISTS  OF  POSSIBLY  ONE  SHARP  FOLLOWED 

BY  ANY  NONCHARACTERJ 
AN  <FN6LISH  TERMlNAL>  IS 
'IDENTIFIER 


OR  fNUMRER 

OR  *sTring 

CR  #cuMMA 

PR  #<iEMlCOLON 

OR  ^PERIOD 

PR  fSHAPP 

PR  ICULON 

PR  *LEFT  #PaREmTHESIS 

PR  «rIgHT  ^parenthesis 

PR  fLEFT  *SOUARE  fBRACKET 

PR  #RlGHT  ISQUARE  tBRACKFT 

OR  #LEFT  JANGLE  IBPACKET 

OR  #RlGHT  IANGLE  #BRACkETS 

PR  tOUESTlpN  tMARK 

PR  loUOTE 

PR  #AMPFRSAND 

PR  fASTFRISK 

PR  tsTAR 

OR  #SLASH 


PR  ^IDENTIFIERS 

OR  fNUMBfRS 
OR  #STRlNGS 
OR  #COMMAS 
OR  t SEMICOLONS 
OR  ^PERIODS 

OR  #SHARPS 
OR  ^COLONS 

PR  #LEFT  fPAREKiTHESES 
OR  fRlGHT  #PARENTHESES 

PR  #LEFT  fSOUARE  ^BRACKETS 

OR  iRlGHT  ISOUARF  ^BRACKETS 

OR  fLEFT  IANGLF  ^BRACKETS 

OR  KPlGHT  IANGLE  ^BRACKETS 

OR  tOUESTlPN  #MApKS 
OR  #OUOTES 

OR  ^AMPERSANDS 
OR  ^ASTERISKS 

PR    #<tTARS 
OR    fSLASHES 


*    6300 

*    6400 

*    6500 

*    6600 

*    6700 

*    6600 

*    6900 

*    7000 

*    7100 

*    7200 

*    7300 

*    7400 

*    7500 

*    7600 

*    7700 

*    7800 

•    7900 

*    8000 

*    8100 

*    8200 

*    8300 

*    8400 

*    8500 

*    8600 

*    8700 

*    8800 

*    8900 

*    9000 

*    9100 

*    9200 

*    9300 
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OR  iVlRGULES 

OR  fPtRCENT  fSTGNS 

OR  InOLLAR  tSIONs 

OR  fCQUAL  ISIGNS 

OR  fNOT  fCOUAL  fSlGNS 

OR  #SIGNS1 


OR  fVlRGULE 

OR  ipERCENT  *SIGN 

OR  fnOLLAR  fSlGN 

OR  ffQUAL  iSIGN 

OR  #NOT  *EOUAL  iSIGN 

OR  #LtSS  ITHAN  #OR  #EQUAL  #TO  t*S!GN 

OR  fG^FATFR  tTHAN  fOR  #£QUAL  #TO  [iSIGN  OR  #SIGN$] 

OR  iLFSS  fTHAN  *sir,N  OR  HESS  #THAn  #slGNS 

OR  #6REATER  «THAN  fSIGN  OR  fGREATER  *ThAn  #SIGNS 

OR  *LEFT  #ARROw  OR  #LEFT  fARROwSj 

A  <TFRMINAL  CLASS  NAME>  IS  AN  ASTERISK  FOLLOWED  BY  EJTHFR  tA  NUMBER 

OR  AN  #1   OR  AN  #N   OR  AN  *S  3 1 
A  <CHARACTFP>  IS  ANY  CHARACTER  BUT  t  it  OR    #<     OR    #> 

OR  f"     OR    #(     OP    #) 
OR  fl     OR    #1     OR    *0 

OR  If     OR    #1     OR    ** 

OR  #♦     OR    *t  OR    *]  1) 

A  <LFFT  RECURSIVE  LIST>  CONSISTS  OF  POSSIBLY  0*E  ffREDUCED  OR  ILEFT 
HRFCURSlVE]  FOLLOWED  BY  A  <BASIC  LlST>   OR   A  <RASIC  LlST> 
FOULED  PY  #CLOSE> 

A  <RlG*T  RECURSIVE  LIST>  CONSISTS  OF  t  #EXPANplNG  OR 

»HGHT  fRFCURSlVE   OR  #R]  FOLIOWED  BY  A  <BASlC  LlST>  OR  A  <PA*lC 

LIST>  FOLLOWED  BY  *OPENJ 
A  <BASlC  LIST>  CONSISTS  OF  A  <LIST  TYPE>  FOLLOWED  BY  A  <SIMPLE 

SYNTACTIC  SYMBOL>  FOLLOWED  BY  POSSIBLY  ONF  #S  FOLLOWEp  BY  POSSIBLY 
ONE  ^SEPARATOR  TyPE>  FOLLOWED  PY  A  <SIMPLE  SYNTACTIC  SvMBOL> 

FOLLO^FD  BY  POSSIBLY  ONE  #S  Jl 
A  <L  1ST  TYPE>  CONSISTS  OF  I 
^NONEMPTY  fLlST 
PR  ^NONEMPTY  ISTRING 

OR  fNONFMPTY  ^SEQUENCE 


9400 

9500 

9600 

9700 

9600 

9900 

10000 

10100 

10200 

10300 

10400 

10500 

10600 

10700 
10800 

10900 
11000 
11100 
11200 
11300 

11400 
11500 

11600 
11700 

U800 
11900 

12000 
12100 
12200 
12300 

12400 
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OR  fPOSSIBLY  fEMPTY  #LIST 

OR  fPOSSIBLY  fEMPTY  fSTRlNG 

OR  fPOSSIBLY  fEMPTY  fSEOUENCE 

OR  fL 

OR  fEL 

OR  fLlST 

OR  fKLEFNE  STAR 

OR  fSEfiuENCF 


]  FOLLOWED  BY  POSSIBLY  ONE  fOF 


OR   [ 


fSTRING 

or  f^LEFNE       ]  followed  py  fOFi 

A  <SFpApATOR  TYPE>  IS  EITHER  fA  t<DEFINlTE  SFPARATOR>  WHlCH  IS 

DEFINED  TO  PE  fSEP   Op  fSEPARATOR   OR  fSEPAPATEO  fPY]]  OR  CA 

[QUESTIONABLE  SEPARATOP>  WHICH  IS  fQ  OP  fPOSSIPLY  FOLLOWED  BY  A 
<DFFlMTE  SFPARATOR>]  ]J 

A  <SFMAKTlC  SYMP0L>  IS  DEFINED  TO  BE  FITHER  [A  <TFST  CALL>  OP  AN 
<Af"MOK  CALL>  OR  A  <BIT  TFST>   PR  A  <BIT  ACTlON>]J 

i  <TFST  CAli>  CONSISTS  OF  M  fT   FOLLOWED  BY  A  <SFMANTIr  pOUTINF 

CA)i>   OR  fA  SHARP  FOLLOWED  PY  A  <SFMANTIC  ROUTINE  CALL>]  ENCLOSED 

IN  <LFFT  BRACKET>  AND  <RIGHT  BRACKETS 
AN  <AcTlPN  cALL>  CONSISTS  OF  A  SHARP  FOLLOWED  BY  A  NUMBER  OR  EITHER 

[fp  IS  OR  fP  fQ]  FOLLOWED  BY  A  <SEMANTIC  ROuTlNF  CALL>) 
A  <RlT  TFST>  CONSISTS  OF  *?  fT  FOLLOWFD  BY  fBIT   FOLLOwFD  BY  ANY 
NONCHAPACTER  FOLLOWED  BY  POSSIBLY  ONE  [fON  OR  fOFFl 
FOlLOwED  PY  POSSIPLY  ONE  r*SET  OR  fRESET]) 

A  <BIT  ACTI0N>  CONSISTS  OF  ff>  fS  FOLLOWED  BY  EITHFR  tfSET  OR  fRESET] 

FOI  I  UwFD  BY  fBIT  FOLLOWED  BY  ANY  NONCHAPACTER  I 

A  <SEmaNTIc  ROUTINE  CALL>  IS  ANY  NONCHARACTEP  BUT  [fBEQIN  OR  fEND] 
FOLLOWED  BY  POSSIBLY  ONF   LIST  OF  NUMBERS  SFPARATED  Bv  COMMAS 

ENCiUsFD  IN  PARENTHESES  FOLlOwEO  BY  POSSIBLY  ONF  [COLON  FOLLOWED 
BY  A  <CCOE  DECLARATIONS     OR   A   <COOE  DEcLARAT I ON>| 


*   12500 

*   12600 

*   12700 

*   12800 

*   12900 

•   13000 

*   13100 

*   13200 

*   13300 

*   13400 

*   13500 

*   13C00 

*   13700 

*   13600 

*   13900 

*   14000 

*   14100 

*   14200 

*   14300 

*   14400 

*   14500 

*   14600 

*   14700 

*   14800 

*   14900 

*   15000 

*   15100 

*   15200 

*   15300 

*   15400 

*   15500 

7^ 


A  <CODE  DECLARATI0N>  IS  EITHER  t<CODE>  ENCLOSED  IN  SOUArE  BRACKETS 
OR  <CODE>  ENCLOSED  IN  JBEQlN  AND  fENOJJ 

<CODE>  CDNSISTS  OF  A  POSSIBLY  EMPTY  LIST  OF  EITHER  [  ANY   TERMINAL 
BUT  [ffPEGIN  OR  HEND  OR  ft  OR  #1)  OR  <CODE  DECLARATION>  ]  J 

AN  <EMPTY  SYMBOL*  IS  DEFINED  TO  BE  fLAMBDA   OR  fEMPTY  OR  A  <LEFT 
BRACKET>  FOLLOWED  BY  A  <RIGHT  BRACKET>I 

A  <NULL  SYMBOL>  IS  DEFINED  TO  BE  #BACK  <SIMPLE  SYNTACTIC  SYMBOL> 
OR  #AHFAO  <SYMB0LIC  TFRMINAL>   OR  #NOT  <SYMROLlC  TFRMINAL>  OR 

JtNOBACK  OR  A[<COMMENT>  WHICH  CONSISTS  OF   EITHER  [#COMMENT  OR 

IC]  FOLLOWED  BY  A  POSSIBLY  EMPTY  LIST  OF   ANY  TERMINALS  BUT  PERIOD 

FOLLOWFD  BY  A  PERIOD!! 
A  <KOmTERMINAL>  IS  A  LIST  OF  ANY  TERMINALS  BUT  t#>  OR  #"1  STARTING 

WITH  ANY  TERMINAL  BUT  [SHARP  OR  STAR]  ENCLOSED  IN  <LEFT  BRACKET* 

ANn  <RIGHT  BRACKET** 
A  <LEFT  BRACKFT>  IS  EITHER  t*<  OR  #"]* 
A  <RIGHT  BRACKET*  IS  EITHER  [#>  OR  #"]* 
A  <SEMANTIC  TAIL*  IS  A  <COOE  DECLARATIONS 
A  <LANGUAGE  NAME  DESlGNATlON>  CONSISTS  OF  ILANGUAGE  FOLLOwED  BY 

COLON  FOLLOWED  BY  ANY  NONCHARACTER J 
A  <COnTrOL  STATEMENT*  IS   EITHER  r 

fPRlNT  «l  FOLLOWED  BY  A  LIST  OF  <PRINT  OpTlON>S  SEPARATED  BY 
COMMAS 

OR  «CLDSF  FOLLOWED  BY  EITHER  f#LP  OR  #LlNEPRlNTFR 

OR  #LINE  iPRlNTER  OP  FMPTY] 

OR  HCOMBINED  IFIRST 

OR  #LONG  #LOOKAHEAD 

OR  <PRPGR*M  NAME>  FOLLOWED  BY  t  APRIORITY   *■   NUMPER  OP 

fCORE   #■   NUMBER   OR 
ISTACK   #■   NUMBER) 
OR  [IPFCijPSIVE  KDFSCENT   OR   fFLOYD  iPRODUCTlON]   tPApSrR 

OR  lEXFCuTARLF   [  IFLPYD  fPRODUCTIONS  OR 


15600 
15700 

15800 
15900 

16000 
16100 

16200 
16300 

16400 
16500 

16600 
16700 
16600 
16900 
17000 
17100 
17200 
17300 
17400 
17500 
17600 
17700 

17800 
17900 

18000 

18100 
18200 

18300 

18400 

18500 

18600 
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*l00kah: AD   OP 

#FlLL  #TAPLFS  ] 
OR  #FLOYD  'PRODUCTIONS  *PFP  'PROCEDURE  «l  NUMBER 
OR  #GROUPS  *PFP  'PRCCFHiPF   »l   NUMBER 
OR  fPROGRAM   iSYMBOL   *l  FOILOWFD  BY  ANY  NONCHAPACTER  Bl)T  NUMpER 

OP  1SPFCIAL  'SYMBPLS  *i  FOLLOWED  BY  A  LIST  OF  ANY  NONC^R ACTERS 

PUT  NUMPER   SEPARATED  BY  COMMASlJ 

A  PROGRAM  NAME>   IS    fTWST  OR  'COMPILER   OR 

*Air,OL  OR  #ISL        OP 

#BKF?rPL  OP  *FPL2PAP    OR  'PAR2ALGJ 
A  <FRINT  OPTION>   IS 

PR  tCHAPACTFRS 

PR  'TERMINALS   # ALPHA BFT I C ALL Y 


'TABLESF  ISIZES 
OR  *TFRMlMLS 


OR  ITRMCHP 
OR  'TRMALr 

OR  'NPNTEPM InaLS 
OP  'NTALF 
OR  #NTNUM 
OP  'INPUT 

OR  'XREF 

OP  'PATTERNS 

OR  »ACTALF 

OR  'ACTNUM 

OP  JPROTAR 

OP  *COMPlNED  IGROuPS 

OP  ISTANDARD 
OR  'DEBUGN 

OR  'NOTHING) 


pR   'TERMINALS   INUMFRKALLY 
PR   #TPMNUM 

pR  'NONTERMINALS  *Al PHAPETITALLY 

PR  'NONTERMINALS  'NUMERICALLY 

PR  'SYNTAX 

PR  'CROSS  'REFFPENCE 

PR  'INDEX 

OR  'ACTIONS 

PR   FACTIONS  IALPHABFTICALL Y 
PR   *ACTIONS  'NUMERICALLY 

PR  'FLPYD 

PR  *PAPSER 

pr  'debugging 
pr  'Everything 


16700 
18800 

18900 
19000 

19100 

19200 
19300 
19400 
19500 
19600 
19700 
19800 
19900 

20000 
20100 

20200 
20300 
20400 
20500 

20600 
20700 

20800 
20900 
21000 
21  100 

21200 
21300 

21400 


3  MINUTES  13.3  SECONDS  FOR  THIS  GROUP) 
END  PF  INITIAL  SCANNING. 


3  MINUTES  13.3  SECONDS  TOT 


COMPLETE  PROTAB  ISl 

LOC.   LEFT  HAND  SIDE 
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RIGHT  HAND  SIDE 


1 
2 
3 

4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
16 
19 
20 
21 
22 
23 
24 
25 
26 
27 
26 
29 
30 
31 
32 
33 
34 
35 
36 
37 
36 
39 
40 
41 
42 
43 
44 
45 
46 
47 
A6 
49 
50 
51 
52 
53 
54 


<NHOLf  PROGRAM 

<TWlNKLEPROGRAM 
<TWlNKLEPROGRAM 
<TWlNKLEPROGRAM 
<TWlNKLEPPOGRAM 

<TWlNKLtPROGRAM 
<TWlNKLEPROGRAM 

<CONTROLSTATEMENT 

<CONTPOLSTATEMENT 

<CONTROLSTATEMENT 

<CONTROLSTATEMENT 
<CONTRriLSTATEMENT 

<CONTROLSTATEMENT 

<CONTROLSTATEMENT 

<CONTROLSTATEMENT 

<CONTROLSTATEMENT 

<CONTROLSTATEMENT 

<CONTROLSTATEMENT 

<CONTROLSTATEMENT 

<CONTROLSTATEMENT 
<CnNTROLSTATEMEM 

<CONTROLSTATEMEM 


IB 

«  EOF  MARK 
<TWlNKLEPROGRAM 
•  EOF  MARK 

> 

!■ 

<LANGUAGESYNT*CTI 
<DUMMY  73 

DUMMY 

2 

> 
> 

l> 

<LANGUAGESYNT*CTI 
<OUMMY  75 

DUMMY 

2 

> 
> 

la 

<LAN6UAGESYNT*CTI 
•  ENO 

DUMMY 

2 

> 

IB 

<LANGUAGESYNTACTI 
•  END 
<CODEOECLARATTON 

DUMMY 

2 

> 
> 

IB 

<languagesyntActi 

DUMMY 

2 

> 

IB 

<LANGUAGESYNTAfTI 
<C0DEDFCLARATIPN 

DUMMY 

2 

> 

> 

IB 

•CLOSE 
•  LP 

IB 

•CLOSE 
•LINEPRINTER 

IB 

•CLOSE 
•  LINE 
•PRINTER 

IB 

•CLOSE 

IB 

•COMBINED 
•FIRST 

IB 

•  LPNg 
•LOOKAWEAO 

|B 

<prOgRamname 

•PPInRITY 
NUMERIC  LITERAL 

> 

IB 

<PpOGR«MNAME 
•  TORE 
«t  —  w 

NUMERIC  LITFRAL 

> 

IB 

«prOgramnamf 

•STACK 
NUMERIC  LITFRAL 

> 

IB 

•RECuRSlVF 

•DESCENT 

•PARSER 

IB 

«F|  OYD 

•PPO0UCTIPN 

•PARSER 

IB 

•EyECUTABlF 

•FIOyD 

•PRODUCTIONS 

IB 

•executable 
•lookameao 

IB 

•EXECUTABLE 
•  FILL 
•TABLES 

IB 

•FLOYD 
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<CONTPOLSTATEMENT 


<CONTPOLSTATEMENT 


<CONTROLSTATEMENT 
<CONTROLSTATFMENT 
<LANGUAGESYNTACTI  DUMMY  1 


<L ANGUAGESYNTACTI  DUMMY  1 

<l ANGUAGESYNTACTI  DUMMY  2 
<LANGUAGESYNTACTI  DUMMY  2 

<L ANGUAGESYNTACTI  DUMMY  2 

<PR0DUCTICN  DUMMY  3 
<PP0DUCTION  DUMMY  3 
NONTERMINAL 

<NONTFRMlNAL 

<APROW 


<APROW 
<APROW 


<APROW 

<DFFIMTION 

DEFINITION 
<DFFINITIPN 
<PPODUCTIpN  DUMMY  a 

PRODUCTION  DUMMY  4 


>  I  t< 


>  i) 


JffSD 

#PPOC 
*  I  It 

NUME 

>  II"  IGPOu 

#PER 
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<fnglishterminal 
<engltshterminal 

<e*glishterminal 


<FKGL  ISHTFRMU'Al 


<EMGLISHTFRMINAL 


<EK<GLISNTFRMINAL 


<englismterminal 

<ekglishterminal 

<fkjgl!shtermimal 

<e^glishtfrhin*l 

<fngl  ishtfrmimal 

<e^glishterminal 

<tfrminalclassname 

<tfrminalclasskamf 

<tfrminalclassname 

<terminalf lassname 

<l  ff tpracket 
< l  f  f tpracket 
<pightpracket 
<rightbracklt 

<Al  PhACHARACTERSTRInG 
<  A  L  P  H  A  C  H  A  P  A  C  T  F  R  S  T  P  I  KJ  G 


> 

1  !■ 

fNOT 

«dummy  ee 

> 

1  IB 

#NpT 
<DllMMY  89 

> 

1  l« 

ILFSS 
I  TuAN 
f  Op 

fF^UAL 
#TP 
fSIGN 

> 

1  !■ 

fLFSS 

fTMAN 

fOP 

fFOUAL 

ITP 

fSIGNS 

> 

1  l« 

fGREATFR 

fTHAN 

#OR 

fFOUAL 

fTP 

fSTGN 

> 

1  •■ 

f  GREATER 
fTMAN 

#np 

fFOUAL 
#TO 

fSIGNS 

> 

1  !■ 

fLESS 

fTMAN 
f  SIGN 

> 

t  IK 

ILFSS 
f  THAN 
fSIGNS 

> 

1  IB 

fGPEATER 

fTMAN 

ISIGN 

> 

1  I* 

fGREATFR 

ITmAN 

fSIGNS 

> 

I  IB 

f  1  FFT 
f ARROW 

> 

1  IB 

f  L  F  F  T 
f ARROWS 

> 

1  IB 

n  +  n 

NUMERIC  LTTrR 

u 

> 

1  IB 

ft  #  ft 

f  T 

> 

1  la 

tt  ^  tt 

f  M 

> 

1  1  B 

ft  ^  ft 

fS 

> 

I  IB 

ft  ^  ft 

> 

1  1  B 

ft  ft  ft 

> 

1  IB 

tt  ^  tt 

> 

1  1  B 

ft  ft  ft 

> 

1  IB 

ANY  SYMBOL 

5 

> 

1  IB 

ft  1  n 

ANY  SYMBOL 

5 

85 


527 

526 

529 

530 

531 

532 

533 

534 

535 

536 

537 

536 

539 

540 

541 

54? 

543 

544 

545i 

546 

547 

546 

549 

550 

551 

552 

553 

554 

555 

556 

557 

556 

559 

560 

561 

562i 

563 

564 

565 

566 

567 

566 

569 

570 

571 

572 

573 

574 

575 

576 

577 

576 

579 

560 

561 

582 

563 

584 

565 


<SYMB0LICTERMINAL  DUMMY  1? 

<SYMBOLlCTERMINAl  DUMMY  12 

<SYMBPLlCTERMINAL  DUMMY  12 

<SYMBflLlCTERMlNAl  DUMMY  12 
<BASICLIST 

<BASICLIST 

<PASICLIST 
<BASICLIST 

<PASICLIST 


>  t  i« 


«SYMB0L1CTERmIN*L  DUMMY  12 


>  I  I 


>  t  I* 


>  I  I 


<BASICLIST 

<LISTTYPE 
<LISTTYPE 

<LISTTYPE 
<LISTTYPE 

<L ISTTYPE 
<LISTTYPE 

<LISTTYPE 

<LISTTYPE 

<LISTTYPE 


>  I  l 


>  I  l 


>  I  I 


<alpmacma 
<symbolic 
<alpmacma 
ii*  ialpha 
<alpmacha 

<alpmacma 
<listtype 
<stmplesy 
<separato 
<simplesy 
ii*  <listtype 
<simplesy 
<separato 
<simpifsy 

IS 

It*  <LISTTYPE 
<S!MPLESY 
<LISTTYPE 
<STMPLFSY 
IS 

<SFPARATO 
<S!MPLfSY 

ll«  <LISTTYPE 
<S!MPLFSY 

ts 

<SEPARATO 
<S!MPLESY 
IS 

II*  <LISTTYPE 
<STMPLFSY 
IS 

iia  INPNEMPTY 

ILIST 
Mb  fNONfMPTY 

ILIST 

IDF 
It.  JNpNfMPTY 

ISTRING 
II*  fNpNpMPTY 

ISTRlNf, 

IOF 
II*  fNPNfMPTY 

ISFQUENCE 
It*  INpNfMPTY 

ISFOUENCE 

IOF 

IPPSSIPLY 

IEMPTY 

II  1ST 
It*  IPRSSIBLY 

IEMPTY 

ILIST 

IOF 

IPOSSIPLY 

IEMPTY 

ISTRING 


RACTE 
TERMI 
RACTE 

RACTE 

RACTE 

NTACT 
RTYPE 
NTACT 

NTArT 
RTYPE 
NTACT 


NTACT 

NTACT 

RTYPE 
NTACT 


RSTRING 

N*L  DUMMY  12 

RSTRING 

RSTRING 

RSTRING 

ICSYMBOL 

ICSYMBOL 

ICSYMBOL 

ICSYMBOL 

ICSYMBOL 
ICSYMBOL 


TCSYMBOL 

NTACTlCSYMBOL 

PTYPE 
NTACTlCSYMBOL 

NTACTlCSYMBOL 
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566 
587 

506 

569 

590 

591 

592 

^93 

596 

595 

596 

597 

598 

599 

600 

601 

602 

603 

604 

605 

606 

607 

608 

609 

610 

611 

612 

613 

614 

615 

616i 

617 

618 

619 

620 

621 

622 

623 

624 

625 

626 

627 

628 

629 

630 

631 

632 

633 

634 

635 

636 

637 

638 

639 

640 

641 

642 

643 

644 


<L ISTTYPE 

<LISTTYPE 
<LISTTYPE 


<L ISTTYPE 
<LISTTYPE 

<LISTTYPE 
<LISTTYPE 

<LISTTYPE 
<LISTTYPE 

<LISTTYPE 

<LISTTYPE 


<LISTTYPE 
<L!STTYPE 

<LISTTYPE 

<LISTTYPE 

<SFPARATORTYPF 
<SEPARATORTYPE 
<SFPARATORTYPE  DUMMY  13 
<SrPAPATORTYPE  DUMMY  13 
<SFPARATORTYPF  DUMMY  13 

<SFPARATORTYPE  DUMMY  1« 
<SFPARATORTYPE  DUMMY  14 

<TFSTCALL 


<TFSTf ALL 

<TFSTCALL 
<TFSTf ALL 

<ACTI0NCALL 
<Af T10NCALL 

<Af TIPKCALL 


> 

1 1" 

•POSSIBLY 
#EMPTY 

iSTRINf, 

#0F 

> 

1  la 

iPOSSlPLY 

iEMPTY 

fSFQUENCE 

> 

1  !■ 

IPOSSlPLY 

iFMPTY 

ISFQUENCE 

tor 

> 

1  la 

#L 

> 

I  la 

fL 

*0F 

> 

t  1* 

#EL 

> 

1  !» 

#FL 

#0F 

> 

1  la 

tLIST 

> 

1  !■ 

ILIST 
*0F 

> 

I  |a 

#KLEENF 

> 

1  l« 

IKLEENE 

« t »» 

#0F 

> 

1  la 

f SFOuENCE 

> 

1  IB 

ISFQuENCE 
tOF 

> 

1  la 

#STRING 
#0F 

> 

1  l« 

#"LEENF 
#0F 

> 

1  la 

<SEPARATORTYpE  DUMMY 

13 

> 

> 

1  1* 

<SFPARAT0RTYPF  DUMMY 

14 

> 

> 

t  IB 

#SFP 

> 

1  !■ 

•SFPARATOR 

> 

1  IB 

^SEPARATED 
fBY 

> 

1  la 

#0 

> 

1  IB 

#P0SSIPLY 

<SFPARATORTYPE  DUMMY 

13 

> 

> 

1  IB 

R|« 

#T 
<SFMANTICR0UTINECALL 

> 

> 

1  IB 

<l  FFT8RACFT 

<SEMANTlCROUTlMECALL 
<RTGHTPRACKfT 

> 

> 
> 

> 

1  IB 

•  •• 
»T 

> 

1  IB 

<lfftbpacket 
<rightpracket 

> 
> 

> 

1  IB 

NUMERIC  LITERAL 

> 

1  1  B 

Ran 

IS 

<SFMANTICROUTlNFCALL 

> 

> 

1  IB 

mmm 
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6451 
6461 

647  I 
6401 
6491 

6501 
651  I 
6521 
6531 
6541 
6551 
6561 
6571 
658i 
659i 

660  t 

661  i 
6621 
6631 
664  I 
6651 
6661 
667  i 
6681 
6691 
6701 
67H 
672i 
6731 
674t 
675l 
6761 
6771 
6781 
6791 
6801 
681  l 

662  t 
6831 
684| 
685» 
6861 
687i 
6881 
6891 
6901 
691  I 
6921 
6931 
6941 
695i 
6961 
697l 
698! 
699l 
7001 
701  I 
702t 
703i 


<ACTI0NCALL 
<ACTI0NCALL 
<BITTFST 

<BITTFST 

<BITTFST 

<BITTFST 

<BITTFST 

<BITTFST 

<PITTEST 

<BITTFST 

<BITTFST 

<BITACTI0n 

<BITACTI0N 

<SFMANTICR0UTINECALL 


<sfmantlcpoutinecall 
<sfmakjticroutinecall 


<SFMANTICR0UTINECALI 
<SFMAMlCR0UT!NECALL 
<SFMANTICR0UT!NECALL 

<SFMaMICPOUTINECaLL 
<SFMANTICROUTI  DUMMY  15 

<SFMAMTICR0UTI  DUMMY  15 
<SFMAMICP0UTI  DUMMY  15 


!■ 


I" 


I* 

IB 

IB 
IB 


«SfMANTICROUTlNECALL 

WAN 

fS 

to 

fT 

<0UMMY  134 
Wan 

fT 

<DUMMY  135 

fT 

<DUMMY  136 
ftp* 

fT 

<DUMMY  137 

fT 

<nuMMY  138 

Kan 

fT 

<0UMMY  139 

fT 

<DUMMY  140 

fT 

<0UMMY  141 
nan 

fT 

<nilMMY    142 

Halt 
fS 

<DUMMY    143 

"•" 
fS 

<DUMMY  144 
ANY  SYMBOL     8 

<CtiDFDFCLARAT*nN 
ANY  SYMBOL     8 
<SFMANTlCROUTl  DUMMY  15 

<CODEDFCLARATlpN 
<SFMANTICR0UTI  DUMMY  15 
<rODEDFCLARATlnN 
ANY  SYMBOL     8 

W  •  If 

<SFMaNTICROUTI  DUMMY  15 

<SFMANTICR0UTI  DUMMY  15 
%* 

NUMERIC  LITFRAL 

NUMERIC  LITFRAL 
ANY  SYMBOL  8 
NUMERIC  LITFRAL 


-^ 


70A 
705 
706 
707 
706 
709 
710 
711 
712 
713 
716 
715 
716 
717 
71ft 
719 
72C 
721 
722 
723 
721 
725 
726 
727 
726 
729 
730 
731 
732 
733 
734 
735 
736 
737 
736 
739 
740 
741 

742 

743 

744 

745 

746 

747 

746 

749 

750 

751 

752 

753 

754 

755: 

756 

757 

756 

759 

760 

761 

762 


<C0DFDFCLARATI0N 
<C0DFDECLARATI0N 


<CPDFDFCLARATIOM 

<C0DE  DUMMY  16 

<C0DF  DUMMY  16 

<CPDE  DUMMY  16 
<C0DF  DUMMY  16 
<C0DE  DUMMY  16 
<NULLSYMBDL  DUMMY  17 

<MiLLSYMB0L  DUMMY  17 

<MILLSYMB0L  DUMMY  17 

<MULLSYMB0L  DUMMY  18 

<NULLSYMB0L  DUMMY  18 

<NULLSYMB0L  DUMMY  16 

<MCNTFRMIMAL  DUMMY  19 

<NDNTFRMlNAL  DUMMY  19 

<MPMTERMIMA|_  DUMMY  19 

<PRINT0PTI0N 

<PPlNT0PTI0N 
<PRINT0PTI0N 
<PPINT0PTI0N 

<PPINT0PTI0N 
<PPINT0PTI0N 

<PRlNT0PTI0N 
<PPIM0PTI0N 
<PRINT0PTI0N 
<PPINT0PTI0N 

<PRINT0PTI0N 
<PPINT0PTI0N 

<PPINT0PT10N 
<PPlMT0PTI0N 
<PPlNT0PTI0N 
<PPIMT0PTT0N 

<PPlNTOPTI0N 
<PPlNTPPTI0N 
<PBINT0PTI0N 
<PPlNTnPTI0N 
<PPINTC1PTI0N 
<PPlMTnPTI0N 


>  it*  <C0DE  DUMMY  16 

> 

>  It*  fRFGIN 

<CPDE  DUMMY  16 

> 

#END 

>  II*  fPFGIN 

fFND 

>  II*  <C0DF  DUMMY  16 

> 

<DUMMY  145 

> 

>  l l«  <C0DE  DUMMY  16 

> 

<CPDFDFCLARATlnN 

> 

>  II*   AMY  SYMBOL     9 

>  II*  <CODFDFCLARAttPn 

> 

>  II*  <CODE  DUMMY  16 

> 

>  II*  #CHMMENT 
it  » 

>  ll*  #c" 

»  n 

>  II*  <NULLSYMBOL  DUMMY  16 

Vf   ft 

> 

>  II*  <Nl*LLSYMBOL  DUMMY  18 

> 

AMY  SYMBOL    10 

>  II*  fCPMMENT 

AMY  SYMBOL    10 

>  II*  #C 

AMY  SYMBOL    10 

>  II*  <NpNTFRMINAL  DuMMY  lAl 

<DIIMMY  78 

>  It*   AMY  SYMBOL    12 

<DUMMY  146 

>  II*  <LEFTBRAC*FT 

<DUMMY  77 

>  II*  fTABLFSF 

fSIZFS 

>  II*  fCHARAcTFPS 

>  II*  #TFRMlNALS 

>  II*  fTFRMlNALS 

tALPHABETICALLv 

>  ||B  fTRMCHR 

>  II*  fTFRMlNALS 

fNUMERlCAl LY 

>  ||*  ITPMALF 

>  II*  UTRMNUM 

>  II*  fMONTERMIMALS 

>  II*  #mpNtErmimals 

f ALPHARFTICALLv 

>  II*  fNTALF 

>  II*  iNDNTERMlNALS 

fNUMFRlCALLY 

>  II*  IMTNUM 

>  II*  fSYNTAX 

>  II*  flMPlJT 

>  ll*  ITROSS 

tRFFERFNCF 

>  ll*  #XREF 

>  ll*  #IMDEX 

>  n*  IPATTERNS 

>  II*  #ACTI0MS 

>  1 l*  #ACTALF 

>  ll*  IACTIOMS 

89 


763 
764i 

765 

766 

767 

760 

769 

770 

771 

772 

773 

774 

775 

776 

777 

778 

779 

78C 

761 

*82i 

783 

784 

785 

786 

787 

788 

789 

790 

791 

792i 

793 

794 

795 

796 

797 

798 

799 

BOO 

801 

802 

803 

800 

805 

806 

807 

808 

809 

810 

811 

812 

813 

81  A 

815 

816 

817 

818 

819 

820 

821 


<PRlNTOPTION 
«PR1NT0PTI0N 

<PRINT0PTI0N 
<PPINT0PTI0N 
<PRlNTOPTION 

<PRINT0PTI0N 
<PRlNTOPTION 
<PPlNTOPTION 
<PRINT0PTI0N 
<PRINT0PT!0N 
<PPlNTOPTION 
<CONTROLSTATEmENT 


DUMMY  20 


<CONTROLSTATEMENT  DUMMY  20 


<PROGRAMNAME 
<PPOGRAMNAME 
<PROGRAMNAME 
<PROGRAMNAME 
<PPOGRAMNAME 
<PROGRAMNAME 
<PROGRAMNAME 
<CONTROLSTATEmENT  DUMMY  21 


<CONTPOLSTATEMENT  DUMMY  21 

<DUMMY  73 
<DUMMY  74 

<DUMMY  75 

<Dl'MMY  76 

<Dl'MMY  77 

<DUMMY  78 
<DUMMY  79 

<DllMMY    80 

<PllMMY    81 

<DUMMY  82 
<DUMMY  83 


•ALPHABETICALLY 

> 

t  la 

fACTNUM 

> 

1 1" 

•ACTIONS 
•NUMERICALLY 

> 

1  l« 

fPROTAB 

> 

t  !• 

•FLOYD 

> 

t  la 

•COMBINED 
fGPOuPS 

> 

1 1> 

SPARSER 

> 

l  i« 

•STANDARD 

> 

1 1« 

•DEBUGGING 

> 

t  la 

•DEBUGN 

> 

t  !■ 

•EVERYTHING 

> 

I  l« 

fNpTHlNG 

> 

1  !• 

<CnNTROLSTATFMrNT  DUMMY  20 
n  -  a 

<PRlNTOPTION 

> 

1 1« 

•PRINT 
it  1 « 

<PPINTOPTI0N 

> 

I  I* 

fTwST 

> 

I  !■ 

#CPMPILER 

> 

1  la 

tALGOL 

> 

1  1* 

f  ISL 

> 

1  !■ 

•PNF2FPL 

> 

1  It 

#FPL2PAR 

> 

1  l« 

#PAR2ALG 

> 

1  l» 

<CPNTROLSTATFMFNT  DUMMY  21 

r 

ANY  SYMBOL 

13 

> 

1  li 

#SPEClAL 
fSYMBflLS 

•9  |  ft 

ANY  SYMBOL 

1-* 

> 

1  la 

w  t  « 

> 

1  la 

»)» 

<prOduction  dummy  a 

> 

1  la 

♦»  J  tt 

<CPDEDFCLARATk 

■ON 

> 

I  H 

ANY  SYMBOL 
<RIGHTBRAC*ET 

12 

> 

1  li 

Ah'Y  SYMBOL 
<DUMMY  U7 

1* 

> 

1  la 

AK'Y  SYMBOL 

11 

> 

I  la 

<NpNTERMINAL 

<APRPW 

<DFFINITION 

> 

1  !■ 

<NpNTERMINAL 

<ARRPW 

<DEFINITION 

> 

1  la 

<NPNTERMINAL 
f WHICH 
<APROW 
<DEFINITION 

> 

1  la 

tFPLLOwED 
*Ry 
<DUMMY  1A8 

> 

1  li 

fFpLLOWED 
fPY 

90 


622  i 

623  i 

824 

825 

626 

627 

828 

829 

830 

631 

632i 

833 

834 

835 

836 

837 

638 

839 

840: 

841 

642  I 

843 

644 

845 

846 

847 

848 

849 

650 

851 

852 

853 

854 

855 

656 

857 

858 

859 

860 

861 

662 

663 

664 

865 

666 

867 

86e 

869 

870 

871 

6  72 

873 
874 

875 
876 
877 
678 

P79 

eeo 


<DUMMY  64 
<DUMMY  65 
<DUMMY  86 
<DUMMY  67 

<DUMMY  88 

<DUMMY  89 

<DUMMY  90 
<DUMMY  91 

<OUMMY  92 
<DUMMY  93 

<DUMMY  94 
<DUMMY  95 
<DUMMY  96 

<Dl'MMY  97 
<DUMMY  98 

<DUMMY  99 
<DUMMY  100 


<DDMMY 
<DUMMY 

<DUHMY 
<  D  U  M  M  Y 
<DUMMY 

<DUMMY 

<DUMMY 

<OUMMY 

<Dl'MMY 

mmy 


101 
102 

103 
104 
105 

106 

107 

108 

109 
110 


<SYMB0L 

> 

1  la 

fFOLLOwED 
#BY 
<DUMMY  150 

> 

1  la 

fFpLlOwED 
*RY 

<symbol 

> 

1  IB 

iFnLLOwFD 
#By 
<OUMMY  15? 

> 

1  !• 

^FOLLOWED 
fBY 

<symbol 

> 

1  IB 

fFOUAL 
fSIGN 

> 

1  1* 

fEOUAL 
fSIGNS 

> 

1  la 

<NFSTEDPRODUrT!ON 

DUMMY  6 

> 

> 

1  la 

<NESTEDPRnDUCTlON 
<KtEENESTAR 

DUMMY  6 

> 
> 

> 

1  !• 

fPARENTHESFS 

> 

1  IB 

fSOUARE 
fBRACKFT5 

> 

1  IB 

JANGLE 
^BRACKETS 

> 

1  IB 

<PRODUrTION  DUMMY 
<DUMMY  96 

3 

> 

1  IB 

<NpNTERMlNAL 

<ARROW 

<PFFINITIPN 

> 

1  IB 

<PPODUCTIPN  fiUMMY 
<PUMMY  98 

3 

> 

1  IB 

<NClNTEPMINAL 
fWHICH 
<APROW 
<OFFINITIPK| 

> 

1  IB 

<NrNTERMINAL 

<APRf)W 

<DEFINJTION 

> 

1  IB 

<NPNTERMINAL 
#WWICH 

<APROW 

<PEFINITIPN 

> 

1  1  B 

<SFE0EPLIST 

> 

1  IB 

<PPOnUCTIDN  ntJMMY 
<DUMHY  104 

3 

> 

1  IB 

<SYMR0L 

> 

1  IB 

<S I MPLF SYNTACTICS Y MB PL 

> 

1  IB 

<SYMBOL 

<PUMMY  84 

> 

1  IB 

<SYMROL 
<SyMBOL 

> 

1  IB 

<SYMBPL 
<DUMMY  65 

> 

1  IB 

<PP00UCTIPN  nl'MMY 
<OUMMY  101 

3 

> 

1  IB 

<SFEDEDLIST 

> 

1  1  B 

<PP0DUCTIPN  nUHMY 
<PIIMMY  111 

3 

91 


efl3|  <OUMMY  109 

0641  <DUMMY  113  >  ■■■  <SEEDE0LIST 

6851  <DUMMY  lit  >  »••  <SEEDEDLIST 

8861  <DUMMY  115  >  »•■  *0IGIT 

887i  <0UMMY  116  >    ■■■  »DIGITS 

8881  <0UMMY  117  >  •»■  'LETTER 

8891  <DUMMY  118  >  ••■  'LETTERS 

;jj; <DUMMY  119  *  "•  ;?h*crIJter 

8921  <DUMMY  120  >  »•"  'SPECIAL 

893|  fCMARACTERS 

6961  <DUMMY  121  >  »»■  'CHARACTER 

8951  <DUMMY  122  >  ,,B  'CHARACTERS 

8961  <DUMMY  123  >    ttm    'RELATIONAL 
a97|  fOPERATOR 

*98t  <Ol'MMY  12«  *     ttn    'RELATIONAL 
fi99|  fOPERATORS 


<DUMMY  125  >  «»•  'NrN 


900i 

901,  fCHARAfTEP 

9021  <DUMMY  126  >  »«■  |^OAMrD, 

903|  fTMARACTERS 

904.  <DUMMY  127  >  •«»  'NPNCHARACTEd 

905l  <DUMMY  128  >  ••»  'NpNCHARAC TERS 

9061  <DUMMY  129  >     ««■  'TERMINAL 

907t  <DUMMV  130  >  » »■  'TERMINALS 

9081  <OUMMY  131  >  «»■   "f" 

909|  <OUMMY  132  > 

9101  <DUMMY  132  >  •«"  <TERMINAL  > 

911  I  <DUMMY  133  >  ll«  fOP 

912|  <TERMlNAL  * 

913t  <DUMMY  134  >  «•■  #BTT 


9Pl 
9151 
9161 


AK'Y  SYMBOL 

fON 
#SfT 


917l  <DUMMY  135                       >  "*  'PIT 

916|  ANY  SYMBOL 

9191  '0K' 

9  20 i  #PE SE  T 

921  I  <DUHMY  136                      >  I  l«  *BIT 

922|  ANY  SYMBOL 

9231  'PN 

9211  <DUMMY  137                       >  «»■  'BIT 

925,  AMY  SYMBOL 

926,  #OFF 
9271  'SET 
928l  <DUMMY  138                       >  ■  •■  'RIT 

929,  ANY  SYMBOL 

9301  *0rF 

9311  fBESET 

9321  <DUMMY  139                       >  »»■  «BIT 

933|  ANY  SYMBOL 

9341  *nfrF 

9351  <DHMMY  HO                       >  »*■  'BIT 

936|  ANY  SYMBOL 

9371  'SET 

9381  <Dl'MMY  141                       >  «»■  'PIT 

939,  ANY  SYMBOL 
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940l 

941  l 

<DUMMY 

142 

9421 

9431 

<DUMMY 

143 

9441 

945  t 

906t 

<DUMMY 

144 

947l 

94fii 

9491 

<DUMMY 

145 

950l 

<DUMMY 

146 

9511 

<DUMMY 

147 

9521 

<DUMMY 

140 

9531 

9541 

<DUHMY 

149 

955» 

<DUMMY 

150 

9561 

9571 

<Dl'MMY 

151 

958l 

<DUMMY 

152 

9591 

960l 

<DUMMY 

153 

#PESCT 

> 

1  IB 

fBIT 

ANY  SYMBOL 

5 

> 

1  !■ 

fSfT 
fBIT 

ANY  SYMBOL 

5 

> 

1  IB 

fPfSrT 
fBIT 

ANY  SYMBOL 

5 

> 

1  IB 

ANY  SYMBOL 

9 

> 

1  IB 

ANY  SYMBOL 

11 

> 

1  IB 

ANY  SYMBOL 

11 

> 

I  IB 

<PP0DUCTI0N 
<DUMMY  149 

DUMMY 

> 

1  IB 

<SYMBOL 

> 

1  IB 

PRODUCTION 
<DUMMY  151 

DUMMY 

> 

1  IB 

<SYMBOL 

> 

1  IB 

<PP0DUCTI0N 
<DUMMY  153 

DUMMY 

> 

I  IB 

<symbol 
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